GNOME Bugzilla – Bug 159676
[playbin] audible click after 3s of playback using playbin
Last modified: 2005-03-10 10:05:30 UTC
When using playbin to playback an mp3 file, there's an audible click (with osssink) or a small gap (with alsasink) after exactly 3s of playback. This happens with all the songs I tried so far.
is it still reproductible with current CVS of totem & gstreamer ? i suppose playbin/decodebin matured a lot since then
Christophe, Is this related to 159211? Does that patch fix it?
I'm using HEAD for gstreamer and gst-plugins, so the patch from bug #159211 should be there, and I still get this small audio gap after 3 seconds. It doesn't happen with all mp3s, but with most of them, and it happens with totem too.
*** Bug 168046 has been marked as a duplicate of this bug. ***
I can reproduce this, but only with mp3 (I missed that part when I looked at this earlier). Here's an OSS log: LOG (0x8b82ad0 - 308247:11:37.381996000) oss( 7853) gstosssink.c(445):gst_osssink_chain:<sink> time: real 0:00:02.977777777, buffer: 0:00:02.977959183 LOG (0x8b82ad0 - 308247:11:37.382695000) oss( 7853) gstosssink.c(445):gst_osssink_chain:<sink> time: real 0:00:03.004081632, buffer: 0:00:06.608979591 INFO (0x8b82ad0 - 308247:11:37.382798000) oss( 7853) gstosssink.c(450):gst_osssink_chain:<sink> need sync: real 0:00:03.004081632, buffer: 0:00:06.608979591 LOG (0x8b82ad0 - 308247:11:41.004453000) oss( 7853) gstosssink.c(445):gst_osssink_chain:<sink> time: real 0:00:06.635079364, buffer: 0:00:06.635102040 A simple mad log shows that there is data in between, which is all lost between mad and osssink (so somewhere at selector ! preroll_queue ! audioconvert ! audioscale). Looking at the preroll_queue, the input is lineair, but the output isn't: LOG (0x9a38d78 - 308247:31:31.116598000) queue_dataflow(10144) gstqueue.c(855):gst_queue_get:<preroll_audio_src0> ___ONLY___ Got buffer of time 0:00:02.977959183 LOG (0x9a38d78 - 308247:31:31.118246000) queue_dataflow(10144) gstqueue.c(855):gst_queue_get:<preroll_audio_src0> ___ONLY___ Got buffer of time 0:00:06.608979591 I think I see why. We are being interrupted while going back to PAUSED, while we're still in the mad chain function. As we do this, we drop buffers for each and every interrupt. Those start when the queue is full and end when the element is PAUSED. All buffers are dropped in the mean time (see interrupt handling in gst_queue_chain()).
Created attachment 38103 [details] [review] quickfix The attached patch worksaround this by simply "ignoring" fullness status on interrupts. It's not really right, but the best you can do...
Rock! I'll test it this evening, hopefully it will still apply to my old gstreamer checkout...
Applied the above.
*** Bug 169602 has been marked as a duplicate of this bug. ***
Just to confirm, this patch fixed my problems, thanks.