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 _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
