INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Comparison of Raspberry Pi 2 vs. Raspberry Pi B+ as Audio Renderer with JRiver  (Read 2938 times)

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5242
  • "Linux Merit Badge" Recipient

So most of the discussion here has focused on running Mediacenter on a Raspberry Pi 2, but I have an extra B+ around, and I was curious how well it would perform as a pure media renderer when compared to a Pi 2.  I had done a few previous unscientific experiments, which suggested that the B+ might play fine, but might be near it's limits.  But that was just based on playing some music and looking at a few realtime read outs, so I figured I could get a better picture with systematic logging.  

So first the test methodology:

A Pi2 and a Pi B+, both setup with the same wi-fi dongle, both running Arch ARM, with the latest version of MC for ARM and a vncserver, both working as clients of the same server, both streaming audio from a hard drive on the server, and both connected to the same model of USB DAC.  Both had a similar number of processes running (the pi 2 actually had a "handicap" of a few extra processes).  The Pi 2 was running stock clocks, and the Pi B+ was overclocked to 1000MHz.  Neither had a screen attached or anyone logged in.  I used gizmo to control them both and started playing the same album (44.1/16 bit FLAC) on both at around the same time.

At the far right of the graph is the CPU usage:



The Pi2 is on the left and the B+ is on the right.   You can see that the Pi2 peaked at about 21% total utilization of one CPU core (system + user), which is effectively only 5% CPU utilization because the system has four cores.  By contrast the B+ peaked at around 87% of its only core.  The B+ is clearly right on the edge, but FWIW I heard no skips on either one with casual listening while passing between them. With higher res material, I would expect that all bets are off.  

You may notice that the scale is different on the two graphs; that represents the fact that the Pi2 has four processors to the B+'s one.  In both cases the top of the graph represents 100% CPU usage, so they're still an apples to apples comparison.  The pi 2 is barely breaking a sweat, while the B+ is hanging on by it's fingernails.

This becomes even more obvious with the load graph:



Again the load in question is on the far right side of the graph.  Here the vertical scale is different, but it's actually a meaningful difference: the graphing tool only goes as high as the highest registered value.  

For folks unfamiliar with Linux load figures , the load represents the number of processes waiting for a processor at any given second.  If the load number is less than the number of processors, you're fine.  If the load number is higher than the number of processors, then things are getting backed up.  You can see that the Pi 2 never gets above .5; with 4 processors that's barely breaking a sweat.  The B+, though, is stuck near 2 with only one processor which means it's at risk of falling behind (I'm frankly surprised that I didn't hear any dropouts with a load like that).

Memory usage was similar in absolute terms (but the B+ has less to go around):



The amount of information Linux provides about RAM usage is dizzying, but the important part of the graph is the Green part at the far right side of the graph (or the "current" reading next to apps int he legend).  You can see that it's roughly the same on both, about 230MB of RAM eaten up by programs, with the rest taken up by various caches.  You can see that the Pi 2 is using a little more memory during playback, but it also has tons more to use.  The B+ doesn't have a lot of room to grow if you do something memory intensive (like fast scrolling through thumbnail lists in gizmo).  Linux doesn't handle memory allocation the same way other OS's do, and I've successfully crashed Pi's by making unmeetable memory demands (especially if you don't have a swap file/partition).

So my original impression of the B+ with MC wasn't far off; it's really hanging on by a thread. But it's also encouraging how easily the Pi2 handles renderer duties.  If anyone is interested in any other graphs, I can provide a few more, but these were by far the most interesting.

All graphs courtesy of Munin.
Logged
Pages: [1]   Go Up