/[pcsx2_0.9.7]/branch/r3113_0.9.7_beta/3rdparty/portaudio/src/hostapi/oss/low_latency_tip.txt
ViewVC logotype

Contents of /branch/r3113_0.9.7_beta/3rdparty/portaudio/src/hostapi/oss/low_latency_tip.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 32 - (show annotations) (download)
Tue Sep 7 03:29:01 2010 UTC (9 years, 11 months ago) by william
File MIME type: text/plain
File size: 3111 byte(s)
branching from upstream revision (http://pcsx2.googlecode.com/svn/trunk
): r3113 to
https://svn.netsolutions.dnsalias.com/websvn/ps2/pcsx2/pcsx2_0.9.7/branch/r3113_0.9.7_beta
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

  ViewVC Help
Powered by ViewVC 1.1.22