[Bug 657076] audioringbuffer: may fail to provide running clock

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=657076

Jan Schmidt <thaytan at noraisin.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |thaytan at noraisin.net
         Resolution|FIXED                       |---

--- Comment #9 from Jan Schmidt <thaytan at noraisin.net> ---
This patch starts the ringbuffer as soon as the first segment is committed by
the writer/decode thread, and then the reader starts trying to read from the
ringbuffer and feed things out to the audio device, but there's only 1
committed segment - so now we're in a race against the writer putting more
segments in place before the reader tries to write them out.

The frequent result is that the reader thread outputs a bit of audio, then
glitches and has to produce silence for a while because the writer fell behind,
then things start flowing out the audio device in realtime, and the writer gets
a chance to catch up.

The previous behaviour was to accumulate a ringbuffer's worth of audio before
starting the ringbuffer and writing things out, giving the writer a (default)
200ms of grace before there'd be any glitch.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.