[gst-devel] gst_event_new_flush_(start|stop) messing up the pipeline...
stbya at yahoo.com
Fri Feb 12 18:32:21 CET 2010
--- On Fri, 2/12/10, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> If audio is not played any longer, then either buffers are
> somewhere before the sink, or buffers are modified to
> silence data, or
> the sink drops/clips them.
All buffers a pushed successfully the 1st and 2nd time (its the same data being pushed both times).
Inserting an identity element prior to the sink and dumping the buffers show that the buffers are, as expected, the same the 1st and 2nd time.
the audiosink appears to be consuming the buffers correctly the first and 2nd time. i.e. I get a series of (with the "at" increasing normally, and for the 1st and 2nd time through):
0:00:04.207250106 12211 0x84b2a80 DEBUG baseaudiosink gstbaseaudiosink.c:1475:gst_base_audio_sink_render:<audiosink-actual-sink-pulse> rendering at 0 368/368
0:00:04.207293501 12211 0x84b2a80 DEBUG baseaudiosink gstbaseaudiosink.c:1485:gst_base_audio_sink_render:<audiosink-actual-sink-pulse> wrote 368 of 368
0:00:04.207318364 12211 0x84b2a80 DEBUG baseaudiosink gstbaseaudiosink.c:1508:gst_base_audio_sink_render:<audiosink-actual-sink-pulse> next sample expected at 368
So, something's getting busted in the pulse audio sink due to the flush_start/flush_stop sent between the first and 2nd time.
The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
More information about the gstreamer-devel