Re: [linux-audio-dev] buffering, latency, cut-outs

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] buffering, latency, cut-outs
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to tammi  13 2000 - 15:18:16 EST


>The current version sometimes cuts out (during heavy UI activity,
>while top is running, etc.), even on a fast machine, and I'm trying to
>understand why it happens and what can be done about it.

You may need to run the thread that generates the audio with real-time
scheduling priority (SCHED_FIFO). But see below for more.

>to set a buffer of 4 fragments of 4K each. One question I have is
>whether these two parameters matter much, or whether it's just the
>total buffer size that matters; if I set it to 0x00200009, for
>example, for 32 fragments of 512 bytes each, I get the same 16K
>buffer.

the number of fragments affects input event latency: how rapidly you
will get notified that there is data to read (and thus how quickly you
can get a given sample from the audio interface's input)

the total buffer size affects output latency: how long after you
compute the value of a given sample until it shows up at the output of
the audio interface.
         
         Another question is whether this is an adequate buffer
>size. We'd like to keep the buffer small for good interactive response
>(Freebirth's major appeal is knob-twiddling).

4K is pretty big, and 4 of them is *huge* for "real time" work. At
44.1kHz and 16 bit stereo samples, thats not far off 1 second output
latency - that is: someone tweaks a knob, and it takes 1 second for
the changed audio to show up.

>The code is not multi-threaded; we're using GTK+'s polling mechanism
>to watch the /dev/dsp file descriptor. I guess this means that GTK+
>could delay things arbitrarily if it doesn't come back and poll the
>file descriptors often enough.

Yep, you'd better believe it can. And does. Even for MIDI data, this
approach has too much jitter. You really need a dedicated thread if
you want good response times.

OTOH, its pretty amazing that you can get dropouts with this much
buffering! What kind of system is this happening on ?
                                
                                But that doesn't really explain the
>problem with top. The alternative would be to have the synth processs
>in one thread and the UI in another.

Thats the approach taken in all of my projects.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST