rhythmbox is slow!

[LGB [Gábor Lénárt]]

Binary package hint: rhythmbox

rhythmbox uses about 10-20% CPU for playing an average MP3 or a streaming radio. It's surprisingly high CPU usage on machine of today, even on Pentium 100 this CPU usage can be produced by optimized players. Is rhythmbox and/or the gstreamer framework slow that? Or is this my fault? Ubuntu 6.10.

[Dave Morley (davmor2)]

Mine isn't moving off 0% amd64bit. Running rhythmbox and playing virgin radio feed.

[Sebastien Bacher (seb128)]

Thank you for your bug. Does totem do the same? What about playing with "gst-launch-0.10 playbin uri=....."? Do you use esd or alsa? What process is using the CPU according to top?

[LGB [Gábor Lénárt] (lgb)]

According to 'top', it's rhythmbox itself. If I try using gst-launch, it uses (I mean process 'gst-launch-0.10') around 10-20% CPU, again. So maybe it's not rhythmbox related, but gstreamer? I've just checked out svn repository of beep-media-player-2 uses gstreamer as well: it uses about the same amount CPU as rhythmbox. Totem uses 10-20% as well. I'm using ALSA directly (no ESD).

[Sebastien Bacher (seb128)]

reassigning to gstreamer0.10 then

[LGB [Gábor Lénárt] (lgb)]

Just tried on an AMD64 box (2GHz CPU), the same, somewhat smaller CPU usage, but 10% is far more than it should be , I think (and it's now only a 128kbit/s mp3 file). Since both the i386 - I've reported the bug from - and this machine is installed by me, I'm thinking about if it's my fault ... I've installed "bad" and "ugly" gstreamer plugins as well, could it cause these problems?

[Sebastian Dröge (slomo)]

You need ugly for mp3 playback anyway.

Do you have gstreamer0.10-fluendo-mp3 installed?

[LGB [Gábor Lénárt] (lgb)]

Yes, its version is 0.10.2.debian-1

[LGB [Gábor Lénárt] (lgb)]

full list:
lgb@vega:~ $ dpkg-query -W "gstreamer0.10*"
gstreamer0.10-alsa 0.10.10-1ubuntu1
gstreamer0.10-audiosink
gstreamer0.10-colorspace
gstreamer0.10-doc 0.10.10-1ubuntu2
gstreamer0.10-esd 0.10.4-0ubuntu3
gstreamer0.10-ffmpeg 0.10.1-2ubuntu1
gstreamer0.10-fluendo-mp3 0.10.2.debian-1
gstreamer0.10-fluendo-mpegdemux 0.10.4-0ubuntu1
gstreamer0.10-gl 0.10.3+cvs20060918-0ubuntu1
gstreamer0.10-gnomevfs 0.10.10-1ubuntu1
gstreamer0.10-gnonlin 0.10.5-1ubuntu1
gstreamer0.10-gnonlin-dev 0.10.5-1ubuntu1
gstreamer0.10-lame
gstreamer0.10-plugins
gstreamer0.10-plugins-bad 0.10.3+cvs20060918-0ubuntu1
gstreamer0.10-plugins-bad-doc 0.10.3+cvs20060918-0ubuntu1
gstreamer0.10-plugins-bad-multiverse 0.10.3+cvs20060918-1
gstreamer0.10-plugins-base 0.10.10-1ubuntu1
gstreamer0.10-plugins-base-apps 0.10.10-1ubuntu1
gstreamer0.10-plugins-base-doc 0.10.10-1ubuntu1
gstreamer0.10-plugins-good 0.10.4-0ubuntu3
gstreamer0.10-plugins-good-doc 0.10.4-0ubuntu3
gstreamer0.10-plugins-ugly 0.10.4-0ubuntu3
gstreamer0.10-plugins-ugly-doc 0.10.4-0ubuntu3
gstreamer0.10-plugins-ugly-multiverse 0.10.4-2
gstreamer0.10-sdl 0.10.3+cvs20060918-0ubuntu1
gstreamer0.10-tools 0.10.10-1ubuntu2
gstreamer0.10-videosink
gstreamer0.10-x 0.10.10-1ubuntu1

[LGB [Gábor Lénárt] (lgb)]

Ok, I've just removed gstreamer0.10-fluendo-mp3 and gstreamer0.10-fluendo-mpegdemux just for testing. Playing mp3 and/or a shutcast stream seems to require about half amount of CPU than before removing those packages, however I think ithis CPU usage (about 6-8%) remains too high (on a 1.7GHz P4 CPU, ok not the newest one, though of course ...).

[Sebastian Dröge (slomo)]

Definitely too much... but how do you measure the cpu usage btw?

[LGB [Gábor Lénárt] (lgb)]

Reported by 'top'. Ok, I know it's not the best method. I've got some complex math software, I tried to run with niced to +10 or such (to avoid r.box to glitch by lacking enough cpu time slice), and discovers that time needed to compute somehing grows while running r.box as well compared to the situation when r.box is not running or not playing anything (also done witth just gst-launch-0.10 playbin). If I compares the time I got about the same CPU usage "stolen" from math software that r.box uses reported by top. I don't know however if it's a correct method or not :)

[Sebastian Dröge (slomo)]

Well, top only reports cpu usage in the exact moment of measurement or at least something very similar to this... i.e. you could even get 100% cpu usage by a app that is sleeping most of the time.

A better way would be something like gkrellm's cpu usage graph or just the cpu time of the progress compared to the real running time.

So could you please start rhythmbox, play music for a defined amount of time and report what the time column of top says (and how long you played music).

[LGB [Gábor Lénárt] (lgb)]

OK, I've just tried this:

time gst-launch-0.10 playbin uri=http://205.188.215.225:8006

real 3m53.003s
user 0m15.509s
sys 0m1.484s

If you even ignore system time, user/real*100.0 gives about 6%.

Also, I've checked "TIME" field just before exiting from playing (CTRL-C), it's the same time that 'user' field reported by 'time'.

[LGB [Gábor Lénárt] (lgb)]

"Also, I've checked "TIME" field just before exiting from playing (CTRL-C), it's the same time that 'user' field reported by 'time'."

I mean TIME field of command "top" :)

[Sebastian Dröge (slomo)]

Ok, and can you please do the same with the same file for the same time with another player?
6% sounds fairly much though...

[LGB [Gábor Lénárt] (lgb)]

Sure, MPlayer (using also alsa autio output) playing from the same streaming source:

real 3m9.331s
user 0m0.444s
sys 0m0.132s

During playback CPU usage is constant 0%, TIME reported by top just before interrupting playback to get the result was 0.53sec (so about half a sec).

[Sebastian Dröge (slomo)]

Ok... sounds better ;)
What about gst-launch-0.10 playbin uri="file:///path/to/file"?

[LGB [Gábor Lénárt] (lgb)]

As I've already written, it does not make too much difference if I play a streaming URL or a local mp3 file ...

Here is the result of gst-launch-0.10 playbin uri="file://..." playing an mp3 for local harddisk (it's a 128kbit mp3 stream):

real 3m0.855s
user 0m12.177s
sys 0m1.372s

It's again 7% which close to 6-7% similar to all players using gstreamer.

CPU time reported by top is 13sec. So the problem is not caused by the fact that I'm playing a streaming stuff or a local file.

[Sebastian Dröge (slomo)]

Ok, forwarded upstream with some more times...

[LGB [Gábor Lénárt] (lgb)]

May not be related, but recently I'm expericencing glitches while hearing music with rbox: no sound for a fraction of second at about every 20 seconds. Local mp3 playing, no CPU load at all ...

[Lionel Dricot (ploum-deactivatedaccount)]

I didn't had any problem with RB under Gutsy but since I upgraded to Hardy, RB takes all the time between 10 and 20% of the CPU ! (I don't use the crossfade plugin).

When my computer does something else, the sound is sometimes garbled by lack of CPU time. This never happened in Gutsy !

[Steinar Bang (sb-dod)]

I have the same experience as Lionel Dricot: RM takes from 10-30% CPU, sound is choppy, and pulseaudio takes around 10-15%CPU.

This happens when playing podcast MP3s on Hardy, but did not happen on Gutsy on the same hardware (Dell Latitude D610 laptop, with an Intel Pentium M processor).

[Steinar Bang (sb-dod)]

>>>>> Steinar Bang <email address hidden>:

> I have the same experience as Lionel Dricot: RM takes from 10-30% CPU,
> sound is choppy, and pulseaudio takes around 10-15%CPU.

> This happens when playing podcast MP3s on Hardy, but did not happen on
> Gutsy on the same hardware (Dell Latitude D610 laptop, with an Intel
> Pentium M processor).

I've found a workaround: stopped rhythmbox, and did the following
command
 sudo /etc/init.d/pulseaudio restart
and then restart rhythmbox.

And then I've tried to stay away from the pause functionality in
rhythmbox. According to some google matches I found, it's the pausing
that causes the CPU % usage.

Perhaps I should file a new bug report about this?

[mind (mind00)]

same problem here too on a 1,6 ghz duo 2 core with 2 gig ram.
eats away between 20-50 % constant.

No problems with gutsy, only since I updated to Hardy.

[Dave Morley (davmor2)]

This has been improved incrementally. I no longer have such an issue with Rhythmbox. How about the others on this bug.

[cmcginty (casey-mcginty)]

yes, I still experience this issue especially when using the music applet.

[Steinar Bang (sb-dod)]

I still experience this issue on a current Hardy system (all updates
accepted since it was originally installed), on an Intel Pentium M
laptop (Dell Latitude D610).

When the CPU usage reaches a certain threshold, the CPU usage of
rhythmbox and pulsaudio increases to take up the rest of the capacity,
and sound turns choppy.

If I kill the other CPU usage, the CPU usage of rhythmbox and pulseaudio
goes down, and can once more play sound normally.

Applications that have caused this behaviour on my system, are
operapluginwrapper when having Opera open on a newspaper page with lots
of flash ads, or maven builds.

[Dave Morley (davmor2)]

This no-longer seem to effect me so much has anyone else noticed a marked improvement?

[Malcolm Lalkaka (mlalkaka)]

I still experience this on Intrepid Ibex.

[Pedro Villavicencio (pedro)]

this has been fixed upstream now, thanks for reporting.

[Sebastien Bacher (seb128)]

the new version is in jaunty now

[ikus060 (ikus060-renamed)]

I've do some research today about this problem as I find it really annoying.

On my side the problem wasn't solved in Jaunty. Rythmbox or Tomet was using 17% of the CPU. My research lead my to alsa. It's seams to be an issue of the sample rate withing the dmix of default alsa device use by gstreamer. The solution was to put the following line in /etc/asound.conf

defaults.pcm.dmix.rate 44100

As I'm not sure it's the same bug/problem I create a new bug report here :
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-base0.10/+bug/391861