← Back to branch summary

~ubuntu-branches/ubuntu/wily/sflphone/wily

« 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): Francois Marier, Francois Marier, Mark Purcell
  • Date: 2014-10-18 15:08:50 UTC
  • mfrom: (1.1.12)
  • mto: This revision was merged to the branch mainline in revision 29.
  • Revision ID: package-import@ubuntu.com-20141018150850-2exfk34ckb15pcwi
Tags: 1.4.1-0.1
http://bugs.debian.org/759576
http://bugs.debian.org/741130
[ Francois Marier ]
* Non-maintainer upload
* New upstream release (closes: #759576, #741130)
  - debian/rules +PJPROJECT_VERSION := 2.2.1
  - add upstream patch to fix broken TLS support
  - add patch to fix pjproject regression

[ Mark Purcell ]
* Build-Depends:
  - sflphone-daemon + libavformat-dev, libavcodec-dev, libswscale-dev,
  libavdevice-dev, libavutil-dev
  - sflphone-gnome + libclutter-gtk-1.0-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
 
dupswapdrop -- the music-dsp mailing list and website: subscription info,
91
 
FAQ, source code archive, list archive, book reviews, dsp links
92
 
http://shoko.calarts.edu/musicdsp/
93
 
 
94
 
 
 
b'\\ No newline at end of file'