← Back to branch summary

~ubuntu-branches/ubuntu/trusty/sflphone/trusty

« back to all changes in this revision

Viewing changes to daemon/libs/pjproject-2.1.0/third_party/portaudio/src/hostapi/oss/low_latency_tip.txt

  • Committer: Package Import Robot
  • Author(s): Mark Purcell
  • Date: 2014-01-28 18:23:36 UTC
  • mfrom: (4.3.4 sid)
  • Revision ID: package-import@ubuntu.com-20140128182336-jrsv0k9u6cawc068
Tags: 1.3.0-1
http://bugs.debian.org/735846
http://bugs.debian.org/727164
http://bugs.debian.org/718178
http://bugs.debian.org/736583
http://bugs.debian.org/722040
http://bugs.debian.org/736746
* New upstream release 
  - Fixes "New Upstream Release" (Closes: #735846)
  - Fixes "Ringtone does not stop" (Closes: #727164)
  - Fixes "[sflphone-kde] crash on startup" (Closes: #718178)
  - Fixes "sflphone GUI crashes when call is hung up" (Closes: #736583)
* Build-Depends: ensure GnuTLS 2.6
  - libucommon-dev (>= 6.0.7-1.1), libccrtp-dev (>= 2.0.6-3)
  - Fixes "FTBFS Build-Depends libgnutls{26,28}-dev" (Closes: #722040)
* Fix "boost 1.49 is going away" unversioned Build-Depends: (Closes: #736746)
* Add Build-Depends: libsndfile-dev, nepomuk-core-dev

Show diffs side-by-side

added added

removed removed

Lines of Context:
daemon/libs/pjproject-2.1.0/third_party/portaudio/src/hostapi/oss/low_latency_tip.txt
 
1
From: "Benno Senoner" <sbenno@gardena.net>
 
2
To: <music-dsp@shoko.calarts.edu>
 
3
Subject: Re: [music-dsp] coding realtime guitar efx on a "pc"
 
4
Date: Saturday, June 30, 2001 8:19 AM
 
5
 
 
6
 
 
7
Andr�,
 
8
you are solving your problem the wrong way:
 
9
you need to use a single threaded solution which does this:
 
10
 
 
11
- set the audio I/O parameters to  fragnum=4  fragsize=128 bytes (=32samples) if
 
12
you use stereo or   fragsize=64 bytes (=32 samples) if you use mono.
 
13
 
 
14
(do not forget to activate fulltuplex with using the _TRIGGER_ stuff)
 
15
(you need to frist deactivate audio and then start the trigger after the DAC is
 
16
prefilled (see below))
 
17
 
 
18
This will give you a total input to output latency of 4x32 samples
 
19
= 128 samples which at 44.1kHz correspond to 2.9msec latency.
 
20
 
 
21
now set your process to SCHED_FIFO  (see man sched_setscheduler)
 
22
 
 
23
after the initialization your code should do more than less this:
 
24
 
 
25
- write()  4 x 32 samples to the audio fd in order to prefill the DAC.
 
26
Without this you will get dropouts.
 
27
 
 
28
while(1) {
 
29
  read() 32 samples from ADC
 
30
  perform_dsp_stuff() on the 32 samples
 
31
  write() 32 samples  to DAC
 
32
  }
 
33
 
 
34
If you use a low latency kernel and pay attention to all the stuff above, then
 
35
you will get rock solid 3msec latencies (plus eventual converter latencies but
 
36
these are in the 1-2msec range AFAIK).
 
37
 
 
38
Using multiple threads , pipes etc, only complicates your life and often makes
 
39
it impossible to achieve these low latences.
 
40
 
 
41
Realtime/audio programming is not an easy task , this is why people often
 
42
fail to get the desired results even if their hardware is low-latency capable.
 
43
 
 
44
The problem is that the final latency depends on the hardware you use,
 
45
the application and the operating system.
 
46
 
 
47
cheers,
 
48
Benno.
 
49
 
 
50
http://www.linuxaudiodev.org  The Home of Linux Audio Development
 
51
 
 
52
 
 
53
 
 
54
 
 
55
 
 
56
 
 
57
On Sat, 30 Jun 2001, you wrote:
 
58
> On 2001-06-29 21:38 +0200, Benno Senoner wrote:
 
59
> 
 
60
> > OSS/Free refuses to use a low # of frags ?
 
61
> > 
 
62
> > That's a myth.
 
63
> 
 
64
> I hope it is. :-)
 
65
> 
 
66
> The fact is that ioctl(SNDCTL_DSP_SETFRAGMENT) succeeds with
 
67
> values as low a 0x10007 (one 128-B fragment) but the latency is
 
68
> still high enough to be clearly noticeable, which suggests that
 
69
> it's *way* above 2/3 ms.  This is on an otherwise idle machine
 
70
> equipped with a SB PCI 128.
 
71
> 
 
72
> But maybe it's me who's doing something wrong. I've been careful
 
73
> to flush stdio buffers or use unbuffered I/O (write(2)) but I
 
74
> may have let something else through.
 
75
> 
 
76
> For example, since the signal processing and the I/O are done by
 
77
> two different vanilla processes communicating via pipes, it may
 
78
> be a scheduling granularity problem (E.G. the kernel giving the
 
79
> I/O process a time slice every 20 ms).
 
80
> 
 
81
> -- 
 
82
> Andr� Majorel <amajorel@teaser.fr>
 
83
> http://www.teaser.fr/~amajorel/
 
84
> 
 
85
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
 
86
> FAQ, source code archive, list archive, book reviews, dsp links
 
87
> http://shoko.calarts.edu/musicdsp/
 
88
-- 
 
89
 
 
90
 
 
91
dupswapdrop -- the music-dsp mailing list and website: subscription info,
 
92
FAQ, source code archive, list archive, book reviews, dsp links
 
93
http://shoko.calarts.edu/musicdsp/
 
94
 
 
95
 
 
b'\\ No newline at end of file'