David Henningsson wrote: > Lennart Poettering wrote: >> On Sat, 09.01.10 10:00, David Henningsson (launchpad.web at epost.diwic.se) wrote: >> >>> 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. >> I am kinda convinced that the actual fix for this issue is this >> patch. Could you check that? >> >> http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=8d356659e69556fa25d0579a66084f820683e2b8 I have now checked it with the latest version of pulseaudio and without my patch posted earlier, I still experience hangs. That and positive feedback given from https://bugs.launchpad.net/bugs/485488 makes me believe that the patch is ready for inclusion upstream (it is already in Ubuntu, thanks Dan). Now onto the next problem. If an underrun occurs in the pulseaudio front-end, it is delivered asynchonously to an underrun callback. This sometimes happens after more buffers are sent (through pa_stream_write()). So these new buffers will end the underrun in parallell with the processing of the underrun in the client, making the underrun obsolete. After all, seen from the client program's perspective, if I write a buffer and it returns underrun (-EPIPE), I assume that all other buffers I've written, which returned successfully, have already been played back. The best action in this case should be to ignore the underrun, if I can determine that the above case is true. Now, how do I do that? I have tried to look at pa_stream_get_timing_info() [1], but I can't find a reliable way to distinguish valid underruns from obsolete ones. // David [1] which needs to be updated, and I can't use pa_wait_operation from the callback so I'll have to use a second callback for the timing info...
