GNOME Bugzilla – Bug 322929
Base audio sink do not resume playback correctly after flush
Last modified: 2006-03-09 15:28:51 UTC
Base audio sink will start sending segments numbered from 0 after flush. The ring buffer does not know about this and these segments are not rendered until segment number reaches the last rendered segment number. The solution to this is to call gst_ring_buffer_set_sample after flush.
Created attachment 55469 [details] [review] Patch to call gst_ring_buffer_set_sample after flushing in baseaudiosink This patch works, though I am not sure if this is the best solution. Especially, I do not like the condition sink->next_sample == (guint64)-1. May be, gst_ring_buffer_set_sample should be called in event handler at FLUSH_STOP?
Created attachment 55742 [details] [review] Updated patch against latest CVS version
Assigning to the taymans
elements that synchronize to the clock and receive a flush need to get their base time redistributed, this usually happens when going from PAUSED->PLAYING. Do you see this behaviour when doing flushing seeks without pausing the element(s)? Just playing the sample ASAP, as is the case with your patch, will definatly break synchronisation in case of multiple streams and is therefore not acceptable.
In my case, I set the sink (which is alsasink) to READY, then I flush, change the source element and set the sink to PLAYING again. The entire pipeline remains in PLAYING state. Use scenario for this would be changing audio track in live streams. I do not know if this approach is 100% correct, but I think that baseaudiosink should forget its internal state when going to READY.
The problem here is that the clock base time is not redistributed in the pipeline since it does not go to PAUSED. This means that the pipeline base time and therefore the stream time just increments. The new stream will just be dropped because it arrives too late in the sink. You can manually reset the stream time of the sink by setting the current clock time with gst_element_set_base_time(). The reason for this is that when there are multiple sinks, they need to have the same base_time to stay synchronized, so it is distributed by the toplevel parent. Another reason is that when you want to switch in a new stream and have it synchronized with the current playing stream, you have to redistribute the old base_time. We need more examples of these mixing use cases... Going to close, please reopen if more info is needed.
Thanks for the explanation. The synchronization stuff is still a bit unclear to me.