GNOME Bugzilla – Bug 745887
playbin: about-to-finish is creating silent gap between mp3 and aac, flac, aiff; m4a
Last modified: 2015-03-11 13:48:07 UTC
Created attachment 298866 [details] about-to-finish samplecode I'm experiencing a bug with the use of about-to-finish and explicit setup of audio-sink property in playbin. In attachment here is my sample code. How to build it: c++ -c -o about-to-finish.o about-to-finish.c -O2 -Wall -Werror -ansi `pkg-config glib-2.0 gstreamer-1.0 --cflags` gcc -o about-to-finish about-to-finish.o `pkg-config glib-2.0 gstreamer-1.0 --libs` Calling about-to-finish file_path.mp3 file_path.aac will play immediatly file_path.mp3 and will wait file_path.mp3 length to start playing file_path.aac Looks like the silence gap is proportional to the mp3 length. This bug does not occur if i'm not setting audio-sink or not setting audio-sink to alsasink. I will upload two test files.
Created attachment 298867 [details] MP3 file
Created attachment 298868 [details] AAC file
I'm using mpegparser and mad to decode the mp3.
This seems to work here; the aac file starts as soon as the mp3 one stops. mpegaudioparse and mad are used. Did you mean mpegaudioparse instead of mpegparser ? I see you set the version to 1.2.1, which is apparently more than a year old, so it is very likely this is a bug that got fixed since.
I noticed a first bug on an arm target with gstreamer-1.4.1. On my host, ubuntu 12.04 with gstreamer-1.0, i'm using gstreamer 1.2.1. But there is also a bug with a flac and then an aiff on gstreamer-1.4.1. The files are quite big, that's why i tried to reproduce it with smaller file on host. I will let you know the following of my investigation. On your side could you try to find the commit which could fix this issue ?
The bug can be reproduced on gstreamer-1.4.1 on arm target.
Seems to work fine with gst 1.4.1 on x86_64. Maybe a bug in ALSA drivers ?
Its totally related to alsasink. If i remove g_object_set(G_OBJECT(pipeline), "audio-sink", audio_sink, NULL); The problem does not appear. Did you take the sample code i provided and built it with the same way i provided? I'm experiencing the bug on a PC and on a imx6q target.
Yes, I'm using your code, command line, and samples.
I'm trying to build my own gstreamer from the repository to see if i can reproduce the bug. Are you on IRC ?
This made me think of something from earlier: https://bugzilla.gnome.org/show_bug.cgi?id=720692 Can you try this patch to see if it helps ?
Yeah its a bit better for 30 seconds, i had to wait 5 seconds to let the sound comes for the next song. There is something related to alsasink.
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=757c90194716ecab3768814306a438c8ec4825dd Looks like this patch is fixing my issue.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository. *** This bug has been marked as a duplicate of bug 737055 ***
Thank you very much for your support! Sorry to have not been able to find this bug issue first.