fighting for rhythmbox

Having noticed that rhythmbox is a pretty nice music player, I though I'd try it on my laptop. Unfortunatly, this was a disaster, thanks to Transmeta(TM) Crusoe(TM) Longrun(TM). Apparently gstreamer gets really confused when the cpu suddenly starts running much slower, so even though it only needs 6% or so of my quite adequate TM5800, if longrun jacks the processor speed up a bit, and then back down, gstreamer decides that a 300 mhz cpu is too slow for it and spews staticy garbage out the speaker. Oops.

Pegging the CPU at anywhere between 800 and 867 mhz and not letting it move around makes gstreamer work fine -- at the expense of my battery. The beautiful thing is that this means that running perl -e '1 while 1' makes this media player play better. Although longrun -s 100 100 is a better idea. Possibly running rhythmbox in the full gnome environment would generate enough CPU activity to make this bug much more rare than it is on my lean and mean ion machine.

This is not an unheard of problem with transmeta CPUs (does it affect others?), but it's never caused media player problems for me before, only affecting some games that calculate timing loops at start, before the CPU has ramped up to full speed, or so on. I don't know if gstreamer breaks because it for some reason needs 3x the cpu as xmms to play the same mp3, or because it has some broken buffering.

Filing a bug on this kind of thing is hard and often yeilds sympathy but little hope of a real fix. Happily, rhythmbox supports a second audio backend, libxine. I've never had any sound problems with xine, and it didn't let me down here either -- and it uses 1/3 the CPU too. Hopefully a version of rhythmbox supporting use of xine can be added to Debian eventually.

Anyway, that's how I spent another several insomniac hours..