[pulseaudio-discuss] [PATCH] pulse: Fix invalid buffer pointer return value

David Henningsson launchpad.web at epost.diwic.se
Fri Jan 15 23:07:53 PST 2010


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...





More information about the pulseaudio-discuss mailing list