Re: [pulseaudio-discuss] Immediate underrun with PulseAudio ALSA plugin when PA and ALSA buffer sizes differ

[Matthew Gregan <kinetik@flim.org>]

At 2012-07-19T10:56:09+0200, David Henningsson wrote:
> What I meant was that I can successfully run your latency test with
> 10 ms here - when I go down to 5 I start to get xruns. In that
> context, getting problems around 50 - 100 ms of latency is quite a
> lot.

Oh, right.  Of the three bug reports I have, two reports are from users with
HDA, the third was using snd_ca01016 and tsched=0 with a fixed 200ms
latency.  On my system (Lenovo W510, 1.73GHz Core i7, HDA/CX20585), PA will
creep up to 46-56ms over multiple days of use (across multiple laptop
suspend/resume cycles), but will run with 16ms fine after restarting PA.

> Meanwhile, you could make a workaround like this in ~/.asoundrc:
> 
> pcm.pulse_no_underrun {
>   type pulse
>   handle_underrun 0
> }
> 
> and then open the device "pulse_no_underrun". With that workaround I
> can run with 1 ms without problem in your latency test. (We can't
> ignore underruns for everyone though, as that would break
> applications depending on these being delivered as well. Been there,
> done that.)

Thanks, this seems to work around the problem the way I'd hoped.  It's not
ideal, because you end up spinning on an instantly ready fd until the PCM's
buffer has filled, but it's better than anything I had managed to cook up in
the meantime.  I've added code to set this at runtime[0] via the local
config interface, inspired by WINE's winealsa.drv, which explicitly enables
rather than disables handle_underrun.

[0] https://github.com/kinetiknz/cubeb/commit/1aa0058d0729eb85505df104cd1ac072432c6d24

Thanks,
-mjg