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
