Music Player Review: CPU Performance

Update: From Ubuntu 12.04, new results!

  • The task: playing 7 minutes of a FLAC file.
  • The tester: Phoronix test suite – specifically “MONITOR=cpu.usage phoronix-test-suite benchmark idle”
  • The tested: Amarok, Banshee, gmusicbrowser, Quod Libet, Exaile, RhythmboxChart

This chart is neat, the indicator in the middle is where the average lies (out of 7 minutes) and the bottom of the line is where the low is, top is where the high is.

If you want to, you can look at their exact charts below. A bit about the results, followed by some possibly relevant tech details.

Amarok
It is the premier music player on the “heaviest” open source desktop KDE. Btw, I was using Xine. Qt.
Amarok
Exaile
Being one of the most CPU intensive it is concerning to me that Xubuntu is considering moving to it. Python, gStreamer.ExaileBanshee
4th Place but quite close to the lead. Mono, gStreamer.
Banshee

 

gMusicBrowser
Low of 1.01%, High of 9.00%. Perl?, Direct to libs/mplayer for playback?
gmusicbrowser

 

Quod Libet
Biggest range, but also lowest average. Odd. Gstreamer, Python.
Quod Libet

 

Rhythmbox
Low and High tied with gMusicPlayer. .15 less average. Nice low usage for the default player. C, Gstreamer.
 rbox

You should be able to use the phoronix test suite’s idle and monitor mode to get similar results. So, the question is, am I kicking someone out for this? For now, Exaile is out.

(but I plan to look at this in more detail specific to Exaile and send my results to (a now defunct page, but it was a page describing how Xubuntu was going to choose a default music player), as well as doing an indepth goodbye review like usual)

Amarok is close to the line as well, but it will stay in for now. Disagree? Please do comment.

Please do attempt to reproduce, preferably on low end hardware so the variations will be more pronounced (as soon as Jaunty is available on my OLPC, I will rerun these on it).

16 thoughts on “Music Player Review: CPU Performance”

  1. >Its interesting to note the difference between banshee and rhythmbox, given that they both use the same underlying gstreamer backend for decoding. So the cpu differences should be just left to whatever each program is doing separate from that.

    Its hard not to look at mono being the problem

  2. >Thank you for this very interesting post ! Even though some people might not like this kind of post, I really think you should feel free to post more if you wish to!
    I'm a rhythmbox-everyday-user and I'm really happy with it except for the memory comsumption (I'm developing my own lightweight media player daemon now). On the other hand, CPU consumption (as we can see here) is indeed very low.

  3. >@gordalott

    More interesting is Exaile. Since it uses the same underlying gstreamer backend for decoding as Banshee, can I use it as conclusive evidence that Python is a major problem?

  4. >I was not trying to compare Mono vs C vs Python. I just included them for those that might be interested, and I was trying to find a pattern as well. I didn't find one.

    The language does choose some of what you will get performance wise, but how you write it matters more. Just look at Exaile vs Quod Libet, both Python apps.

  5. >hey there,
    i just wanted to note that in your reviews you sometimes write "gmusicplayer" instead of "gmusicbrowser". i find that somehow confusing and thought maybe others do too, so i thought i'd mention it.

    other than that i can only confirm gmusicbrowsers low cpu usage (with the mplayer backend; with gstreamer it's a different story) and especially like the fact that the user can choose the backend (mpg321,gstreamer,mplayer,icecast).

  6. >Could you please let us know about the results you get with Exaile 0.3.0 alpha 3 under the same testing conditions ? I didn't run tests but I know some commits were about CPU usage improvements 🙂

  7. >Exaile 0.2.14 is old and has some very inefficient code in it. Exaile 0.3.0 which is due out very soon is a complete rewrite that improves performance and functionality in many aspects of the player, and it is this version that Xubuntu is considering moving to. I would be most interested if you could compare the latest alpha of 0.3.0 as well, since it is a better indicator of exaile's current and future performance. Python itself is generally not a speed limiter – quod libet is also written in python and performs (apparently) much better than 0.2.14.

  8. >@insulae:
    I am using 0.2.99.3.

    I'm not sure the best way to test MPD, cause it really isn't fair cause it doesn't have a GUI to update. 😛

    Please, if you want to do your own more detailed test, grab a copy of phoronix test suite (included in Jaunty) and run the command in my article. It also has a lot more functionality :).

    Thanks!

  9. >I couldn't get the phoronix test suite to work (version in gentoo is old and didn't appear to save data properly), but I did run some basic tests of my own on Exaile 0.3.0 vs Exaile 0.2.14 vs Quod Libet. I measured cpu time (via htop) before and after playing one 4-minute FLAC file, and subtracted one from another to get the amount used during actual playback. The results:

    9.90 – Exaile 0.3.0 bzr
    9.36 – Exaile 0.2.14
    8.07 – Rhythmbox 0.11.6
    7.47 – Quod Libet 2.1

    So 0.3.0 is only about 5% more intensive than 0.2.14. Clearly plenty of room for improvement in future versions, but not a big difference from the past.

    (note: i did not test banshee because it does not, so far as i can tell, have any easy way to play just one file and then stop)

  10. >I do find the test interesting, however – but that's my hearing and my system – I found Rhythmbox performing poorly when I play my audio files. The more dynamic is Exaile (could the high CPU usage related?) then Quod Libet. With the former CPU usage average is about 70%, with the later 50%

  11. >Thanks for the comparisons, very interesting to see the difference.

    Was Amarok ver. 1.4 or 2.x? Also curious what Listen would come in at (if it is still being developed)

Leave a Reply to reacocard Cancel reply

Your email address will not be published. Required fields are marked *