GNOME Bugzilla – Bug 724371
Long delay after transition to PLAYING state
Last modified: 2015-03-19 17:07:10 UTC
This may be more of a question on how to further debug this scenario rather than a bug itself. My application has the following pipeline: pipeline_ = gst_pipeline_new("audio-player"); bus_ = gst_pipeline_get_bus(GST_PIPELINE(pipeline_)); source_ = gst_element_factory_make("filesrc", "file-source"); decoder_ = gst_element_factory_make("mad", "mp3-decoder"); sink_ = gst_element_factory_make("autoaudiosink", "audio-output"); The play() function just transitions to READY, changes the filesrc, then transitions to PLAYING. void AudioManager::PlayMp3File(const char* file) { gst_element_set_state(pipeline_, GST_STATE_READY); g_object_set(G_OBJECT(source_), "location", file, NULL); gst_element_set_state(pipeline_, GST_STATE_PLAYING); I can hear audio output nearly instantly on the first call to PlayMp3File(file1), but it takes nearly 5 seconds after the second call to PlayMp3File(file2) to hear audio output. I measured the delay using GST_DEBUG=4 ./myapp from the transition time to PLAYING to when audio starts outputting and gst_query_position() returns sane info indicating track progress. How can I further debug this delay? Thanks! Arch Linux: linux 3.12.9-2 gstreamer 1.2.3-1 Files are on an SSD. Note: I don't see this issue on my other linux platform: Linux Mint: linux 3.8.0-35 gstreamer 1.0.6-1 Files are on an HDD.
Can you get a debug log with GST_DEBUG=6 and attach it here? Or a testcase that allows to reproduce this would help even more. Is the delay between first and second file maybe about the same as the duration of the first file?
GST_DEBUG_NO_COLOR=1 GST_DEBUG=6 output attached. Once setting the filesrc and changing to GST_STATE_PLAYING, I set a 100ms timer to query position/duration. I normalize these values to 1-1000 and use this to set a GUI slider position. If you look at the log output, search for "setting slider value". You will see the first track starts making progress, and then a lot of "setting slider value 0" where the long delay I mention above is happening, and then the 2nd tracks eventually starts making progress.
Created attachment 269338 [details] typescript.zip
Sebastian, you are on to something. The delay is as long as how much the first track is played.. play track1 for 5s, start playing track2, 5s delay, track2 starts audio output. play track1 for 20s, start playing track2, 20s delay, track2 starts audio output.
There's a good chance this is fixed in master. I can't find the relevant bug but such a bug (delay equal to the running time of the previous part) was fixed a while back.
Let's close this then for the time being. Brian, could you re-test with git master or >= 1.5.x once it's been released? Alternatively, a small test program that demonstrates the issue would also help enormously, then we can verify if it's fixed or see where the problem is. Note that in your pipeline you should really have an mpegaudioparse in front of mad.