On Fri, 12.02.10 09:20, David Henningsson (launchpad.web at epost.diwic.se) wrote: > > What happens here either there is a large period (~30 seconds to > > 90 seconds) of silence before audio begins to play fine, or I get > > bursts of audio (5-10 seconds) followed by very long bursts of > > silence. I know this is related to prebuffering, but beyond that I > > am lost. > > First, make sure that your tlength is at least two-three time as large > as mixlen. My guess is that you supply a tlength but for some reason > fail to fill it properly, so you get underruns on the PA frontend, which > makes PA increase tlength even more, leading to higher prebuffering (and > latency). Uh, 2-3x seems very arbitrary to me. I don't see where such a rule would ever apply. > > 2. How do the meaning of pa_stream_writable_size and pa_simple_get_latency differ in terms of the fill state of the buffer? > > pa_stream_writable_size returns the number of bytes that may be written > using pa_stream_write. Actually, to be fully correct you are welcome to write both less or more than pa_stream_writable_size() returns. Generally however the rule is that you should pass at least what it returns. A good reason to pass more is when your app generates blocks of PCM and hence cannot generate the exact number of samples _writable_size() indicated. A reason to pass less is for example when you are reaching the end of your stream, or otherwise want to (temporarily or not) stop passing audio data. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
