CPU 60% and High Temperatures with Cross-Fader and low bit-rate MP3

Bug #141390 reported by TJ
This bug report is a duplicate of:  Bug #73744: rhythmbox is slow!. Edit Remove
4
Affects Status Importance Assigned to Milestone
Rhythmbox
Fix Released
Unknown
rhythmbox (Ubuntu)
New
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: rhythmbox

Gutsy 64-bit, Rhythmbox 0.11.2.

Playing large MP3 audio-books (in this case a 10-hour file - 286.9 MB) causes Rhythmbox to keep the CPU(s) under heavy load and drives temperatures towards the high-end of their range. Expected normal temperature is 52C but I'm seeing 64-69C as one or other core is being driven hard constantly.

System Monitor Processes tab reports Rhythmbox is sleeping and using 32% CPU. CPU history tab shows one CPU at 60%, the other around 8%. Occasionally the load swaps cores (presumably as threads start/stop).

As soon as playback is paused both cores drop to 2% usage and the temperature rapidly falls back to normal levels.

Playing 'general' audio tracks (3-8 minutes) there is no problem.

Using an alternative music player such as XMMS there is no problem.

TJ (tj)
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote : Re: CPU 60% and High Temperatures playing large MP3s

Thank you for your bug. Does it happen if you play the mp3 using "gst-launch-0.10 playbin uri=file:///path/to/audio"?

Changed in rhythmbox:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
TJ (tj) wrote :

No it doesn't. CPU usage is as expected using:

$ gst-launch-0.10 playbin uri=file:///home/all/Music/Books/Discworld/06.\ Wyrd\ Sisters/Terry\ Pratchett\ -\ Wyrd\ Sisters.mp3

Revision history for this message
TJ (tj) wrote :

It seems it isn't related to the file-size; that is just a coincidence.

I've found that MP3 tracks of any length that are 32kbps or 64kbps (mono or stereo) cause this whilst 128kbps tracks are okay. Most of the audio-books are 32 or 64 kbps although I found one that was 128kbps, and it played without the CPU load issue. Almost all my music files are 128kbps or higher.

The only thing I can think of to explain it is some kind of up-sampling although 32/64kbps to 128kbps isn't exactly intensive.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Do you have the issue using gst-launch or not? Could you attach a mp3 example to the bug?

Revision history for this message
TJ (tj) wrote :

Which issue with gst-launch? I think I answered that question on comment #2 - gst-launch doesn't have the problem.

Try this file.

Revision history for this message
Sebastien Bacher (seb128) wrote :

you answered the question and then added a new commnet that it was a coincidence which make it not clear if you tried on the same file or an another one which doesn't trigger the bug. Do you have the issue using totem? Does changing the crossfading option makes any difference?

Revision history for this message
TJ (tj) wrote :

Ahhh, okay, I see what you mean now.

1. Since your suggestion I am doing each test with gst-launch as as comparison - if it is not 'as expected' I'll report it.
2. Playing the Small Gods file with gst-launch behaves normally - no excessive CPU load.
3. Disabling Cross-Fading in Rhythmbox doesn't improve the situation - CPU load as high as ever.
4. Totem-gstreamer has no problems with CPU load with this file.

Now for something strange. After your cross-fading suggestion I decided to go through the options and disable/enable things to see if there was a difference whilst the file is playing.
I started in plug-ins by (stupidly) disabling them those that were enabled (only a handful were) and as soon as I did the CPU load dropped to the expected minimum. I tried enabling them one-at-a-time but now I don't seem to be able to recreate the issue.

This is/was a default install of Rhythmbox with regard to plug-ins, I don't use it that much and hadn't had occasion to look at the options there.

I do notice that the MTP plug-in causes the high CPU load whilst Rhythmbox is starting but that is all, and I'm reasonably sure it wasn't enabled. I've not had any MTP devices connected when the CPU load was high.

So it looks like it was some kind of strange plug-in interaction which has now 'gone away'. I'll report back in a couple of days to confirm it seems fully resolved.

Revision history for this message
TJ (tj) wrote :

Well, the issue has recurred today. I had been using it without Cross-fader. Before a PC restart I re-enabled Cross-fader in Rhythmbox.

After the restart Rhythmbox is back to using a large amount of CPU and pushing the temperatures up. I tried disabling the plug-ins, one-at-a-time, but with them all now disabled the issue continues.

So it looks like your earlier question about the Cross-fader was on the money. Is there any further diagnosis I can do to further determine why this happens?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Not sure, maybe you would have better chance to get a reply on bugzilla.gnome.org, that looks like an upstream issue, they know the code better and the desktop team has to prioritize its work since we have limited ressources and that one will not likely be worked soon since we didn't get many user complains about it

Changed in rhythmbox:
status: Incomplete → New
Changed in rhythmbox:
status: Unknown → Confirmed
Changed in rhythmbox:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.