GNOME Bugzilla – Bug 385061
[audioresample?] investigate high CPU usage
Last modified: 2009-01-26 22:09:14 UTC
Hi, GStreamer seems to be fairly slow compared to mplayer when decoding a mp3... almost 7 times slower. This is with latest releases of everything (and pre-releases of ugly/ffmpeg) and happens on all kinds of different hardware and older versions too. See https://launchpad.net/distros/ubuntu/+source/gstreamer0.10/+bug/73744 for more informations and times... Bye time gst-launch-0.10 filesrc location=foo.mp3 ! decodebin ! alsasink real 4m33.095s user 0m13.876s sys 0m0.556s time gst-launch-0.10 filesrc location=foo.mp3 ! ffdemux_mp3 ! ffdec_mp3 ! alsasink real 4m33.239s user 0m13.260s sys 0m0.580s time mplayer -ao alsa foo.mp3 (using ffmpeg mp3 decoder) real 4m34.673s user 0m1.768s sys 0m0.152s time mplayer -ao alsa foo.ogg real 4m27.382s user 0m1.000s sys 0m0.120s time gst-launch-0.10 filesrc location=foo.ogg ! decodebin ! audioconvert ! alsasink real 4m27.834s user 0m17.364s sys 0m0.668s From the Ubuntu bug report: mplayer: real 3m9.331s user 0m0.444s sys 0m0.132s gstreamer: real 3m0.855s user 0m12.177s sys 0m1.372s Bye
No one uses the ffmpeg mp3 decoder, try with mad please.
The first time is with mad, the second with ffmpegs mp3 decoder. They're both almost the same...
Maybe I should also explicitely note that the last two times are from decoding an ogg vorbis file with gstreamer and mplayer. So it doesn't make much difference what kind of file is decoded but seems to be more a general problem somewhere.
There's a good chance that this is audioresample, if the hardware doesn't support the sample rate of the input files. Audioresample is known to be ridiculously slow. It could be optimised, if anyone cared enough. In the vorbis case, audioconvert isn't helping - it's slow too, though not so bad.
Are you on a multicore machine? I'm deeply suspicious of the results "time" is giving me here on mine: time gst-launch-0.10 filesrc location=/home/jan/media/mp3/Dire\ Straits\ -\ Money\ For\ Nothing.mp3 ! mad ! fakesink silent=true *snip*..... real 0m4.045s user 0m22.881s sys 0m0.164s Hey, look - on a single cpu HT machine, it's somehow achieving 22 seconds of user cpu time in only 4 seconds of wall clock time. My conclusion is that "time" is pretty useless on these machines, for some reason. Use valgrind, or measure average cpu load, or measure wall clock time while decoding 'as fast as possible' (if you can get mplayer to do that, I've never managed it) None of this is intended to detract from MikeS' comment that audioresample badly needs optimisation.
My results are from a single core machine... I'll provide times with "decoding as fast as possible" (i.e. gst-launch-0.10 ... fakesink / mplayer -ao null) in some minutes.
Every test is called 4 times and the average real time is used. mplayer -quiet -vo null -vc null -ao pcm:file=/dev/null test.mp3: ~16.63s mplayer -quiet -vo null -vc null -ao pcm:file=/dev/null test.ogg: ~6.47s gst-launch-0.10 filesrc location=test.mp3 ! decodebin ! fakesink silent=true: ~6.77s gst-launch-0.10 filesrc location=test.mp3 ! decodebin ! audioresample ! "audio/x-raw-int,rate=48000" ! fakesink silent=true: (one run) 3:21 gst-launch-0.10 filesrc location=test.mp3 ! ffdemux_mp3 ! ffdec_mp3 ! fakesink silent=true: ~6.96s gst-launch-0.10 filesrc location=test.ogg ! decodebin ! fakesink silent=true: ~6.92s gst-launch-0.10 filesrc location=test.ogg ! decodebin ! audioresample ! audioconvert ! "audio/x-raw-int,rate=48000" ! fakesink silent=true: (one run) 3:17 So the evil one here seems to be audioresample (my soundcard can only do 48khz)... and in general we're as fast as mplayer when it comes to decoding, even much faster when decoding via ffmpeg's mp3 decoder for some reason (probably older ffmpeg in mplayer).
Heh, told you it needed optimising. Even so, I'm surprised at that big a jump. I'll be suspicious of the ffmpeg based decoder's speed in gst until after I've compared the sample output to mad and the fluendo decoder's. I notice in the launchpad report that a few people are find that the Fluendo mp3 decoder is currently quite slow. That also surprises me..... I expected people would notice much sooner. The plain-C version of Fluendo mp3 decoder is based on the original dist10 sample code (because nothing else had a suitable license), and even though it's been cleaned up and optimised quite a bit, there's still a long way to go to truly be a great decoder in that mode (It's open source, please feel free!) That doesn't apply to the IPP based binary build, which on this machine is slightly faster than mad. The decoding in both builds is very accurate though. It produces identical output to mad to within 1 bit - at least in version 0.10.3 and higher (Ubuntu should upgrade, 0.10.2 had a nasty distortion bug) The 0.10.4 flump3dec decoder contains a modest speed boost, on the order of 10%.. still not nearly enough. Really, until it is optimised further, its only benefit is that it has a patent license.
Raw decoding is more or less as fast with GStreamer as it is with mplayer here on my machine (amd-k7) too, so seems indeed like audioresample/audioconvert might be one of the culprits here. Renaming bug accordingly for the time being.
I have a similar problem with similar numbers. Is there some sort of workaround or has there been progress made on the bug? Where can I find more information?
*** Bug 481181 has been marked as a duplicate of this bug. ***
Faster resampling elements are now in gst-ffmpeg CVS and gst-plugins-bad CVS (gst/speexresample).
Ok, speexresample is (except unit test that will come soonish) ready IMHO. What options do we have to replace audioresample by this to finally fix this bug? speexresample was more than two times faster than audioresample in my tests.
FYI, ffaudioresample is available in the GST_FFMPEG_NO_MIRROR branch of gst-ffmpeg. It's 5-10 times faster than audioresample and doesn't introduce latency.
Sebastian: twice the speed doesn't sound very good. Audioresample, as it currently stands, is _insanely_ slow. Jean-Marc wrote speexresample with being (reasonably) fast as a specific goal; I'd be very surprised if it were only twice as fast as our current audioresample. Are you sure your benchmarks were right? Are we doing something silly in the gstreamer wrapper? Edward: I don't think we'd want to trust an audio resampler written by the ffmpeg people. Certainly not as the default; people who want to explicitly use it in their applications can, of course.
Michael, the default quality setting of the speex resampler uses a filter 4 times as large as audioresample. If using the quality with the same filter size speexresample is about 6 times faster than audioresample. My benchmarks were done with time gst-launch-0.10 audiotestsrc num-buffers=1000 ! "audio/x-raw-float,rate=44100" ! speexresample ! "audio/x-raw-float,rate=48000" ! fakesink Also I'm probably doing nothing insane in there ;)
Maybe we should use a shorter filter by default, then? Twice as fast as audioresample puts it in the "too slow" category for me (though audioresample is 'embarassingly slow'); we should use something by default that is a balance between good quality, and fast.
Well, I used the default that JM promoted in the sources :) Of course we could use a lower quality as default if that's preffered. But apart from these trivial changes, what can be done to fix this bug except telling people to use another resampling element and changing it in playbin? (Also see bug #499693 btw)
When audioresample was written, it was doing 40x real-time on a 400 Mhz CPU with no acceleration (this was pre-liboil). It's gotten slower over time because people keep disabling stuff instead of fixing it.
Ok, newer benchmarks now :) with default quality speexresample is: 3 times as fast for 48khz->44.1khz 4 times as fast for 44.1khz->48khz 8 times as fast for 24khz->48khz 5 times as fast for 48khz->24khz as audioresample. For 48khz->44.1khz this is 30x real time on my machine.
*** Bug 512617 has been marked as a duplicate of this bug. ***
*** Bug 523621 has been marked as a duplicate of this bug. ***
2008-11-27 Sebastian Dröge <sebastian.droege@collabora.co.uk> * configure.ac: * docs/plugins/Makefile.am: * docs/plugins/gst-plugins-base-plugins-sections.txt: * docs/plugins/gst-plugins-base-plugins.args: * docs/plugins/gst-plugins-base-plugins.hierarchy: * docs/plugins/gst-plugins-base-plugins.interfaces: * docs/plugins/gst-plugins-base-plugins.prerequisites: * docs/plugins/inspect/plugin-adder.xml: * docs/plugins/inspect/plugin-alsa.xml: * docs/plugins/inspect/plugin-audioconvert.xml: * docs/plugins/inspect/plugin-audiorate.xml: * docs/plugins/inspect/plugin-audioresample.xml: * docs/plugins/inspect/plugin-audiotestsrc.xml: * docs/plugins/inspect/plugin-cdparanoia.xml: * docs/plugins/inspect/plugin-decodebin.xml: * docs/plugins/inspect/plugin-ffmpegcolorspace.xml: * docs/plugins/inspect/plugin-gdp.xml: * docs/plugins/inspect/plugin-gio.xml: * docs/plugins/inspect/plugin-gnomevfs.xml: * docs/plugins/inspect/plugin-libvisual.xml: * docs/plugins/inspect/plugin-ogg.xml: * docs/plugins/inspect/plugin-pango.xml: * docs/plugins/inspect/plugin-playback.xml: * docs/plugins/inspect/plugin-queue2.xml: * docs/plugins/inspect/plugin-subparse.xml: * docs/plugins/inspect/plugin-tcp.xml: * docs/plugins/inspect/plugin-theora.xml: * docs/plugins/inspect/plugin-typefindfunctions.xml: * docs/plugins/inspect/plugin-uridecodebin.xml: * docs/plugins/inspect/plugin-video4linux.xml: * docs/plugins/inspect/plugin-videorate.xml: * docs/plugins/inspect/plugin-videoscale.xml: * docs/plugins/inspect/plugin-videotestsrc.xml: * docs/plugins/inspect/plugin-volume.xml: * docs/plugins/inspect/plugin-vorbis.xml: * docs/plugins/inspect/plugin-ximagesink.xml: * docs/plugins/inspect/plugin-xvimagesink.xml: * gst/speexresample/gstspeexresample.c: (plugin_init): * gst/speexresample/Makefile.am: * tests/check/Makefile.am: * tests/check/elements/speexresample.c: (setup_speexresample), (GST_START_TEST), (test_pipeline): Rename the moved speexresample to audioresample, integrate into the build system and remove the old audioresample from the build system. Fixes bug #558124, #385061, #346218, #116051.
*** Bug 465814 has been marked as a duplicate of this bug. ***