After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745887 - playbin: about-to-finish is creating silent gap between mp3 and aac, flac, aiff; m4a
playbin: about-to-finish is creating silent gap between mp3 and aac, flac, ai...
Status: RESOLVED DUPLICATE of bug 737055
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-03-09 11:27 UTC by Stephane Cerveau
Modified: 2015-03-11 13:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

about-to-finish samplecode (3.59 KB, text/x-csrc)
2015-03-09 11:27 UTC, Stephane Cerveau
MP3 file (308.84 KB, audio/mp3)
2015-03-09 11:28 UTC, Stephane Cerveau
AAC file (314.09 KB, audio/mp4)
2015-03-09 11:28 UTC, Stephane Cerveau

Description Stephane Cerveau 2015-03-09 11:27:34 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.
Comment 1 Stephane Cerveau 2015-03-09 11:28:15 UTC
Created attachment 298867 [details]
MP3 file
Comment 2 Stephane Cerveau 2015-03-09 11:28:36 UTC
Created attachment 298868 [details]
AAC file
Comment 3 Stephane Cerveau 2015-03-09 11:29:25 UTC
I'm using mpegparser and mad to decode the mp3.
Comment 4 Vincent Penquerc'h 2015-03-09 12:30:18 UTC
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.
Comment 5 Stephane Cerveau 2015-03-09 13:02:38 UTC
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 ?
Comment 6 Stephane Cerveau 2015-03-09 13:25:48 UTC
The bug can be reproduced on gstreamer-1.4.1 on arm target.
Comment 7 Vincent Penquerc'h 2015-03-09 14:43:14 UTC
Seems to work fine with gst 1.4.1 on x86_64.
Maybe a bug in ALSA drivers ?
Comment 8 Stephane Cerveau 2015-03-09 14:57:16 UTC
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.
Comment 9 Vincent Penquerc'h 2015-03-09 14:58:53 UTC
Yes, I'm using your code, command line, and samples.
Comment 10 Stephane Cerveau 2015-03-09 15:00:37 UTC
I'm trying to build my own gstreamer from the repository to see if i can reproduce the bug.
Are you on IRC ?
Comment 11 Vincent Penquerc'h 2015-03-09 15:07:29 UTC
This made me think of something from earlier:

Can you try this patch to see if it helps ?
Comment 12 Stephane Cerveau 2015-03-09 17:29:38 UTC
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.
Comment 13 Stephane Cerveau 2015-03-10 17:59:24 UTC

Looks like this patch is fixing my issue.
Comment 14 Sebastian Dröge (slomo) 2015-03-10 23:13:11 UTC
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 ***
Comment 15 Stephane Cerveau 2015-03-11 13:48:07 UTC
Thank you very much for your support! Sorry to have not been able to find this bug issue first.