[gst-devel] gst_event_new_flush_(start|stop) messing up the pipeline...

[S Boucher]

--- 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
> dropped
> 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/