[gstreamer-bugs] [Bug 545807] [baseaudiosink] audible crack when starting the pipeline
bugzilla-daemon at bugzilla.gnome.org
Thu Apr 30 00:00:38 PDT 2009
If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
GStreamer | gst-plugins-base | Ver: git
------- Comment #11 from Stefan Kost (gstreamer, gtkdoc dev) 2009-04-30 07:00 UTC -------
Created an attachment (id=133631)
avoid taking more segments out of the ringbuffer that actually have been filled
Without the fix, the writer writes more data (3 extra buffers) than the
producer has produced initially. So 3 extra zero buffers are written, when all
ALSA buffers have been filled out.
This is heard as an audible glitch when MP3 etc GST is started initially.
You can see from below, (not patched), from the line:
0:00:01.227691675 0xcfe80 DEBUG ringbuffer
gstringbuffer.c:1626:gst_ring_buffer_commit_full: pointer at 22, write to 20-0,
that the diff goes to -2, which MUST NOT be the case.
The patch basically generates an initial write barrier to the writer thread, so
that it doesn't initially write more buffers than it should.
So when the producer has (segment / 2) amount of new input in the buffers, it
wakes up the writer thread. Then everything goes as has always been the case.
This also should fix the issues where the producer goes "slow" that it actually
provides an glitch while playing back the media (very rarely, but it's heard).
Because now the producer is running at the head, not at head ~ writer head.
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.
You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=545807.
More information about the Gstreamer-bugs