GNOME Bugzilla – Bug 724231
appsrc: handle flushing from send_event
Last modified: 2014-06-10 16:34:41 UTC
I have the following pipeline: appsrc ! alsasink I push buffers (from a buffer pool) into the appsrc to play a audio stream (track). When I switch tracks I need to force clear the pipeline to directly start playing the new data. The problem is that I can't figure out how to do this without getting a ~500ms residue audio playback from the previous buffers. This is my code to clear/flush the pipeline which i run each time i start delvering new buffers from a new track: gst_element_send_event(GST_ELEMENT(pipeline), gst_event_new_flush_start()); gst_element_send_event(GST_ELEMENT(pipeline), gst_event_new_flush_stop(resetTime)); gst_element_set_state(GST_ELEMENT(appsrc), GST_STATE_NULL); gst_element_get_state(GST_ELEMENT(appsrc), NULL, NULL, 5 * GST_SECOND); gst_element_set_state(GST_ELEMENT(appsrc), GST_STATE_PLAYING); gst_element_get_state(GST_ELEMENT(appsrc), NULL, NULL, 5 * GST_SECOND); This code works fine in Win32 (with directaudiosink) but on linux on the RPI it plays <= 500 ms of the previous song even after i done the flushing. Any ideas? Thanks, \\ Theo
(In reply to comment #0) > I have the following pipeline: appsrc ! alsasink > > I push buffers (from a buffer pool) into the appsrc to play a audio stream > (track). When I switch tracks I need to force clear the pipeline to directly > start playing the new data. > > The problem is that I can't figure out how to do this without getting a ~500ms > residue audio playback from the previous buffers. > > This is my code to clear/flush the pipeline which i run each time i start > delvering new buffers from a new track: > > gst_element_send_event(GST_ELEMENT(pipeline), gst_event_new_flush_start()); > > gst_element_send_event(GST_ELEMENT(pipeline), > gst_event_new_flush_stop(resetTime)); > > gst_element_set_state(GST_ELEMENT(appsrc), GST_STATE_NULL); > gst_element_get_state(GST_ELEMENT(appsrc), NULL, NULL, 5 * GST_SECOND); > gst_element_set_state(GST_ELEMENT(appsrc), GST_STATE_PLAYING); > gst_element_get_state(GST_ELEMENT(appsrc), NULL, NULL, 5 * GST_SECOND); > Sending a flush and then setting the element to NULL and back to PLAYING is redundant. Either operation should be enough for your case. > This code works fine in Win32 (with directaudiosink) but on linux on the RPI it > plays <= 500 ms of the previous song even after i done the flushing. > > Any ideas? Can you share an example application to reproduce the problem? > > Thanks, > \\ Theo
Actually i seem to have to do both flush and statechanges (NULL -> PLAYING) to make it work at all on Windows. * I just no a flush I get the audio residue problem. * If i just do state changes it doesn't reset the pipeline clock. So I need to do both. I think that the appsrc element is not behaving correctly with flushes. I'm using gst_app_src_push_buffer to queue buffers during playback, maybe the flush simply doesn't clear the queued buffers? However, on linux/arm i still get the residue even when doing the statechange (NULL->Playing) which is really weired. I'll try to see if I can make a sample application.
Hi, any updates?
Fixed in master, fix will be available in 1.3.3 release. This adds flush handling to appsrc and should make it work for your case by only flushing. commit bbf226d9d6ab19cb21d50bc5264dd3b750070ce4 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Tue Jun 10 12:59:53 2014 -0300 appsrc: add send_event handler for flushing Adds a send_event handling for allowing appsrc to flush its internal data, allowing users to flush the pipeline without setting it to null. https://bugzilla.gnome.org/show_bug.cgi?id=724231