[pulseaudio-discuss] Multiple PulseAudio bugs affecting mplayer2 users

[Tanu Kaskinen]

On Sun, 2012-07-29 at 01:12 +0300, Uoti Urpala wrote:
> From 2a76e113939e9d2d7dc7deda69c59762faa75ad6 Mon Sep 17 00:00:00 2001
> From: Uoti Urpala <uau at glyph.nonexistent.invalid>
> Date: Sat, 28 Jul 2012 23:26:21 +0300
> Subject: [PATCH 2/3] core: fix broken rewinds after sink suspend
> 
> pa_sink_input_request_rewind() set certain state in the sink_input
> object, asked the sink for a rewind, and relied on the sink then
> calling pa_sink_input_process_rewind() to clear the state set earlier.
> However, when uncorking a stream on a suspended sink, a rewind request
> occurs while the sink is still in suspend state. The sink ignores the
> request and the process_rewind() function it not called. In this case
> nothing would clear the state of the sink_input object, in particular
> sink_input->thread_info->rewrite_nbytes == -1. While this state was
> set, further calls to pa_sink_input_process_rewind() would not ask the
> sink to rewind. Thus rewinds for the stream would be permanently
> broken, at least until some external source (like another stream)
> triggers a rewind on the sink and it calls process_rewind.
> 
> Rewrite the pa_sink_input_request_rewind logic so that it always asks
> the sink for a rewind; possibly asking twice should not be harmful as
> the sink already combines requests. This ensures such "deadlock"
> between the objects cannot occur. However, there is still the problem
> that the state from an ignored request may be combined with another
> request done significantly later; but at least this breaks at most one
> rewind and will not cause a catastrophic permanent broken state.
> Possibly this could be avoided by detecting a suspended sink and
> either resetting state or calling process_rewind directly, but I
> haven't tried to investigate that.

I sent a patch that makes sinks to process all rewind requests, even
when suspended. I think that should fix these issues.

-- 
Tanu