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