> 'Twas brillig, and David Henningsson at 09/01/10 09:00 did gyre and > gimble: >> The pulse ALSA plugin has been known, for a while, to not work properly, >> causing underruns, hangs etc. I sat down yesterday trying to figure it >> out, and I'm pretty certain this patch improves the situation, but I >> don't mind getting some help testing it before it is committed upstream. >> >> Related bug: https://bugs.launchpad.net/bugs/485488 >> >> The patch is for the alsa-plugins tree at git.alsa-projects.org. > > I applied this to 1.0.22 (cleanly) and sadly it's not helping my test > case using mpg123. I've tried to debug the mpg123 issue a little further. Assuming my analysis is correct, what happens is that pa_stream_cork() is called just after the first 623 samples have been written, which makes pulseaudio start playback. This leads to an underrun, pa will run out of the 623 samples before new samples are coming in. This is to compare with buffer_attr.prebuf parameter, which is 66152 (or 16538 frames). I have tested to not call pa_stream_cork() the first time, and that fixes the issue with mpg123 here. But I don't know if the right decision is doing that, or if we should change the behavior of pulseaudio itself - if someone calls pa_stream_cork() to uncork, but we have less than prebuf samples in queue, should pulseaudio really start playback anyway? Another questionable behaviour of the ALSA plugin is that "prepare", which is called after every underrun, disconnects (as in pa_stream_disconnect) and reconnects, causing two bad things, 1) flickering in pavucontrol and 2) buffers being dropped. However I assume that this somewhat is a safety mechanism to return to a known state. But perhaps one could avoid that in some cases, such as an underrun? // David
