GNOME Bugzilla – Bug 318767
[alsasink] choppy playback of some files
Last modified: 2005-10-31 09:42:38 UTC
Please describe the problem: this seems to be a regression - playback of http://stef.tvk.rwth-aachen.de/~nazgul/zeugs/Unplugged%20-%20Eric%20Clapton%20-% 2007%20-%20Layla.mp3 is choppy with gst mad plugin from cvs. Plugin Details: Name: mad Description: id3 tag manipulation and mp3 decoding based on the mad library Filename: /opt/gnome2/lib/gstreamer-0.8/libgstmad.so Version: 0.8.11.1 License: GPL Package: GStreamer CVS/prerelease However playback is fine with Plugin Details: Name: mad Description: id3 tag manipulation and mp3 decoding based on the mad library Filename: /usr/lib/gstreamer-0.8/libgstmad.so Version: 0.8.8 License: GPL Package: GStreamer Plugins (Debian) Origin URL: http://packages.qa.debian.org/gst-plugins0.8 Steps to reproduce: 1. get http://stef.tvk.rwth-aachen.de/~nazgul/zeugs/Unplugged%20-%20Eric% 20Clapton%20-%2007%20-%20Layla.mp3 2. play the file using rhythmbox 3. Actual results: Expected results: Does this happen every time? Other information:
installed library on my system: libmad0 0.15.1b-2.1 MPEG audio decoder library this is the lib both plugins use
I bet this is because of bug #318273. Cheers -Tim
Indeed I am using alsasink. Changing to OSSSINK remedies. however most files play fine with alsasink. *** This bug has been marked as a duplicate of 318273 ***
Yeah, that's probably because most audio files are encoded with a sampling rate of 44.1KHz (which is also the rate used with audio CDs) so no resampling is necessary there (what audioscale does, wrongly in this case). The reason it works with osssink is that osssink uses the timestamps/durations on the buffers differently. Cheers -Tim
Christian, could you check whether things work for you now if you use alsasink device=hw:0 instead of just alsasink (with the patch from bug #318273 applied. I think your problem might be due to another alsasink problem. Does lowering the alsasink period-size value help? Cheers -Tim
heh ok this works gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink device="hw:0" and this still *fails* gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink I am not that familiar with gst and no idea how to change the period-size what do you want me to do?
Does any of this work: gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=4096 gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=2048 gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=1024 gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=512 ?
All work just fine.
Just to double check, gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=8192 does not work, right?
gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink period-size=8192 plays choppy. same with both period-size=1024/4096 seems to play just fine. I can upload the file again if this is of any help.
Created attachment 54082 [details] [review] propsed patch (alsa_periodsize.diff) Could you try this patch and see if things work now when you just do gst-launch-0.8 filesrc location=foo.mp3 ! mad! alsasink Cheers -Tim
For posterity: the bug can be reproduced like this as well without the file: gst-launch-0.8 sinesrc ! audio/x-raw-int,rate=22050,width=16,depth=16 ! alsasink It's a plain mp3 with a sample rate of 22050.
yes this patch works for me well done
Great, thanks for confirming. 2005-10-31 Tim-Philipp Muller <tim at centricular dot net> * ext/alsa/gstalsa.c: (gst_alsa_set_property), (gst_alsa_get_property), (gst_alsa_probe_hw_params), (gst_alsa_set_hw_params): * ext/alsa/gstalsa.h: When doing _set_period_size_near(), see what period size was actually set in the end and continue working with that value instead of just assuming our desired period size was accepted. Should fix choppy playback for some folks, esp. with streams that have a low sampling rate (#318767). Cheers -Tim