[pulseaudio-discuss] Detecting low buffer level of a sink output

[David Henningsson]

On 04/14/2012 06:35 PM, Marcel Müller wrote:
> I tried to detect the buffer level of a sink output by calculating the
> difference between write_index and read_index in pa_timing_info. But I
> did not get the wanted effect.

Not completely sure why this does not work, but I would use 
pa_stream_writable_size in conjunction with tlength to determine how 
full or empty the buffer is.

> In fact the difference never falls below the exact equivalent of 2000ms.
> Even if the sound has completely stopped because of a buffer underrun.
> Furthermore, the lowest level of exactly 2000ms is not reached before
> the sound stops, but somewhat later. I am curious whats happening here.
> Is there a better criterion than the buffer level?
> I considered the over all latency, but it depends on user configuration
> of the PulseAudio server.
>
> Context:
> I use the asynchronous API and the main loop runs at time critical
> priority. But I do not want the entire engine to run at time critical
> priority all the time, because on slow machines with complex filters the
> thread may eat 100% CPU, which causes the UI to lock up. To avoid this I
> want to raise the priority of the engine only if the output buffer is
> low and only for a limited period. So if a user uses a configuration
> that is too hard for his CPU, he gets drop outs instead of a dead lock.

Be aware of that there are threads in pulseaudio that run at normal 
priority and that your audio data passes through. So this approach might 
not be a 100% guarantee, unfortunately.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic