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/1aa0058d0729eb85505df104cd1ac07243...
Thanks, -mjg