Saturday, 7 January 2017

MEASUREMENTS: Raspberry Pi 3 as USB Audio Streamer (with recommended CRAAP config & TIDAL/MQA arrives)

A few weeks ago, I got this question from Josh Xaborus in my previous post on the Raspberry Pi 3 + HiFiBerry DAC+ Pro measurements:
Have you measured the USB output from the RPI3 to a USB DAC to see if it's "clean" like the ODROID?
Good question Josh, and perceptive as well. I had not posted anything on the Raspberry Pi 3 specifically, whether there was any difference to be found streaming to the same USB DAC as compared to say the ODROID-C2. Let's have a good look at this and see if we can arrive at some facts and come to some conclusions...


In the image above, we see my Pi 3 in the red box. Notice the USB cable out to the DAC (which is "Unconnected!" of course since the power is pulled) is plugged into the upper left USB port (if you're wondering). The power supply for the Pi 3 is the same "freebie" FujiFilm branded switching 5V 1.0A supply that came with an old digital camera years ago that I used in the ODROID-C2 measurements.

To make this an apples-to-apples comparison, let's use essentially the same set-up as what I did before:
"Streaming Device" [Raspberry Pi 3] --> 6' generic shielded USB --> TEAC UD-501 DAC --> shielded 6' RCA --> Focusrite Forte ADC --> USB cable --> Windows 10 computer
For convenience, I'll just use the most recent piCorePlayer 3.02 streaming from my Logitech Media Server (recent 7.9.0 nightly build) computer down the gigabit ethernet to the Raspberry Pi 3 (remember, unlike the gigabit ODROID-C2, the Pi 3 is only capable of up to 100Mbps) and then the rest of the chain is as described above. As usual, what is important is to check the analogue output of the DAC and make sure there's no evidence of excess noise or distortion. Also, we'll have a look at the jitter test measurements.

I. RightMark

First, let's run a few of the usual distortion measurements...

16/44 as usual to start:

Composite graphs of the data above:

As you can see, I'm using the same DAC with the Pi 3 (piCorePlayer) and ODROID-C2 (Volumio) using the same switching power supply. The Microsoft Surface Pro 3 (foobar) computer is also feeding the TEAC UD-501 by USB, running on battery playing the test signals.

No significant difference at 16/44 demonstrated.

How about hi-res into 24/96:

And the composite graphs:

Anyone spot any difference they think would be audible?

Finally, for completeness - 24/192:

And a couple graphs (RightMark's graphing display unfortunately has bugs with 192kHz graphing of crosstalk and the IMD+N sweep):


Results are rather self explanatory! Nothing to worry about and all three devices result in the same analogue output from the TEAC USB DAC.

II. Jitter

Here are the Dunn J-Test FFT's in the typical 16-bit and 24-bit versions:

For comparison, here is the same thing with the ODROID-C2 to TEAC UD-501 using the same USB cable:


Nothing much to see, but there is a tiny sideband pair visible with the ODROID-C2 that's not there in Raspberry Pi 3 although the low-level "skirting" may have been less with the ODROID. In any event, I cannot imagine this making significant audible difference way down there in the noise floor.

III. Conclusions


A. General Impressions
The Raspberry Pi 3 playing to the USB DAC is indeed "clean"; as in just as noise-free and "bit-perfect" as other computer-based servers sending to a good asynchronous DAC (no surprise and further discussed here last summer).

It sounds great to me and I would not be able to tell a difference between the Pi 3 or ODROID-C2, or Surface Pro 3 sending the audio through ASIO. Maybe the only difference between the machines would be the hum of the Surface computer's internal fan on a quiet night with very low ambient noise in the sound room. Furthermore, there is no objective difference of significance to be found with the RightMark tests using 16/44, 24/96 and 24/192 signals. As for the time domain, there is no evidence of any difference between devices tested using the Dunn J-Test signal that would have any audible impact.

May I also remind everyone that this is all with an inexpensive switching power supply... No noise of significance even with the 192kHz test beyond the audible spectrum. I think it would be nice if the believers in linear power supplies can show some evidence that noise can be significantly improved at the DAC output since the cost of linear power supplies can be many times that of a Pi 3!

It is not surprising that commercial audio companies would use the Pi in their products. For example, the heart of the Bryston BDP-Pi is a Pi motherboard with HiFiBerry Digi+ - nice case, I'm sure excellent power supply and display screen although US$1295 is quite a chunk of change... (I appreciate their honesty in naming the Pi openly since I'm sure they could have just hidden that fact or used an even less capable SBC.)

B. Recommended CRAAP configuration!
But there's more! Here at the Musings, I like my articles to be "value added", so let me offer you an audiophile tip. Remember that the Pi is only acting as a headless streamer when I use piCorePlayer; all it's being asked to do is to listen to the ethernet communication port for audio data, parse it, and pass it along to the USB DAC. This takes barely any processing power. Therefore, based on Convoluted Rationalizations And Audiophile Perceptions (CRAAP), some out there might say:
Lower clock speed --> less power use --> less CPU noise --> better sound!
Better aligned clock speeds
--> less random & periodic jitter --> better sound!
Less power use
--> less strain on power supply --> less noise & jitter (cuz it's like that) --> better sound!
So, my technique for an "audiophile sounding" Pi 3 would be to tweak the config.txt for your device. Easily done, just stick the microSD card for your piCorePlayer install into your computer's card reader, edit config.txt file on the root directory, adding this:
arm_freq=800
sdram_freq=400

core_freq=400
gpu_freq=300

over_voltage=-4

sdram_over_voltage=-4

gpu_mem=16
to the "# uncomment to overclock the arm" part so it looks like this:

This will underclock your Pi 3 to 800MHz (from 1200MHz), slow down the DDR2 memory to 400MHz (from 450MHz), downclock the graphics core to 400MHz and GPU specifically to the lowest amount at 300MHz because you won't need it, and minimize the amount of memory the GPU can see to just 16MB. Notice the CPU:RAM speeds are an integer 2:1. In fact internally the memory access is doubled to 800MHz; so essentially 1:1. Integer multiples are good, right? No nasty fractional harmonics :-).

Furthermore, we down-volt the RAM and CPU by about 0.1V from stock 1.2V to 1.1V (each value on the over_voltage parameter is worth 0.025V). I would love to achieve 1.0V but this was not stable enough for my RAM so 1.1V across the motherboard sounds better for both CPU and RAM. Why 1V you ask? It's like "the ONE", man... Salvation, man... Pono, ya know? Ultimate beauty in unity!

Practically, it'll run cooler (my machine's CPU temperature fell from ~50°C to ~40°C idle fanless), likely the Pi will last even longer, demand less from the power supply, plus it'll save you a few pennies if the machine is on 24/7/365 as well as the planet. And of course it'll sound better due to all the above reasons reducing noise and jitter! (Cuz it's like that...)

Now, you must be wondering, how slow did the Pi 3 become? Well, the synthetic BogoMIPS went from 76.80 to 51.20 in /proc/cpuinfo. This means that the Pi 3 CPU is now about the speed of a Pi 2 but of course with a more advanced CPU capable of 64-bit instructions and components capable of handling a processor 50% faster. But more importantly, for audio streaming, it's still just as responsive (while sounding better of course!). Here's the "top" command while streaming 24-bit 384kHz audio:

4.5% CPU usage at its peak while it's buffering! Through most of the track, the CPU use is less than 2%. This is an example of truly how little processing is needed for computer audio for a streamer delivering bit-perfectly to your DAC. It's an example also of how little processing power it takes to stream FLAC, even decompressing ultra-high resolution stereo 24/384 data these days. If anything it's demanding more from the ethernet system when streaming uncompressed stereo 24/384 at ~18.5Mbps. Of course make sure to turn off the WiFi if not needed (sounds better!):
Don't worry about the science, my friends... It just sounds much better now that I have tweaked the parameters. Bass is deeper. Treble even more trebly. Soundstage goes back a mile with 360° envelopment. Vocalists sound like they have become incarnate. Smooth as Louis XIII cognac. Thick curtains I was literally blind to were lifted. Any prior jitter totally slaughtered. Noise floor as silent as the best anechoic chamber on Earth. Based on my proprietary Value-Added Audiophile Gauge of Ultimate Enjoyment (VAAGUE) analysis, this tweak is easily able to elevate your Pi 3 to the sound quality of any US$690 (with switching power supply) streamer out there...

In all seriousness, have a good listen to these CRAAP optimizations; you might be pleasantly impressed with how well they bring you closer to the "absolute sound". I've been using these settings for most of the last month with rock solid stability running 24/7.

--------------------------

To close off (very seriously now), I think it's worth highlighting one of the great things about objective measurements. Results, when done right, can be easily replicated with excellent precision. Notice that in the RightMark results, we do see small variations but the values are typically <1dB at the extremes like below -100dB noise floor among the machines using the same DAC. This is the kind of inter-test variability I've seen over the years. It's easy to pick out what DAC is being measured as each one has its own unique RightMark signature, noise floor, or "digital filter composite" graph when I measure them. Furthermore, those ODROID-C2 and Surface Pro 3 measurements were done almost 5 months ago compared to the Raspberry Pi 3!

How often have you seen subjective reviewers try to compare the sound of devices based on memory and admit that such comparisons are based on recall from a remote experience? If a reviewer listened to a digital streaming device or DAC 5 months ago, and is now reviewing another device, are we to have faith that for a high fidelity device, a reviewer's perception would be so acute as to not only reliably detect differences, but also be reliable in holding on to that memory for recall months later? I can honestly and humbly submit that I would not have such "golden ears" nor have the memory to recall with any certainty... I'm quite sure that normal, rational people would agree with that generalization.

What more to say? Raspberry Pi 3 users, enjoy your DAC fed through the USB port. Sounds good to me and certainly measures the same as both the ODROID-C2 and Microsoft Surface Pro 3 connected to an asynchronous DAC.

So, TIDAL / MQA arrives...
In other news, I see that MQA has capitulated and will be releasing software decoding, announced at CES 2017 (this is exactly what I suggested back in April 2016 even though it will compromise their claim of "end-to-end authentication" since the DAC will not be specifically MQA-approved). Apparently it'll be available with Audirvana Plus 3 coming late January for Mac and TIDAL "Master" software playback will start immediately (about time). Not surprising that they've decided to proceed down this route after >2 years since the big initial announcement. I guess they finally realized that folks aren't going to run and buy a new DAC just for MQA. It looks like software decoding will upsample the 44/48kHz stream to 88/96kHz to present to the DAC. IMO this is totally fine since I don't see any point in 176/192kHz. I'm curious to see how they're going to spin the idea that the hardware/firmware variety of MQA will "sound better". They must do this, otherwise who will bother buying MQA hardware? And what manufacturer will bother spending money for licensing if there's no perceived public value?

The next chapter has now started with MQA. It's now up to the consumer - let's see if the public cares about MQA over the next 6 months once the initial hype, bugs, fanboy/cheerleader press chatter, and potential confusion subsides... (Check out some early "play by play" discussions on Computer Audiophile.)

Finally, it looks like the music industry is still trying to convince people that their typically loud, over-compressed to the point of clipping music, or old analogue remasters are worth spending money on in "high resolution"... Honestly, are you guys in the music industry actually making decent money off the extra effort? I wouldn't be surprised if the balance sheets look pale if not red. There comes a time to honestly reconsider what one is doing and what is the truth. No, it's not that I think high-resolution is totally useless, rather, it's hard to hear the difference unless done right. Put the money into promising mainstream artists and start producing recordings worthy of the "high-resolution" moniker that the public cares about. Then sell and educate the people when there's something worthy of their hard-earned dollars (especially given the premium charged for these downloads). Hanging out at trade shows putting on a brave face, promoting already ubiquitous hi-res capable hardware when there's barely any decent hi-res media, and throwing money at the advertising side is pure window dressing over an essentially empty shell. Sure, keep throwing money at it, but in my opinion failure is inevitable when there is no substance.

Whatever the Industry does, the music plays on with tons of great stuff out there. Hope you're all enjoying the music! It's a fantastic time to be a music lover and audiophile... And it's all getting less expensive when you hear what devices like the Raspberry Pi 3 can do.

PS: Forgot to mention that the Pi 3 + piCorePlayer + CRAAP works well and sounds great as a Roon endpoint/streamer. Just turn on "Enable Squeezebox Support" in the settings and make sure any instance of LMS is turned off in your network. I have not looked at the Linux variants in Volumio, RuneAudio or Archphile but I assume similar CRAAP config can be done for these DLNA/UPnP streaming software options.

23 comments:

  1. Why not use and measure the Raspberry Pi 3 as a pure Roon endpoint, using the Bridge software (RAAT as the network transport). This is great new technology worthy of a few data points!

    ReplyDelete
    Replies
    1. I'm willing to help for a generic Raspbian install and Roon Bridge that could be used either with the DAC+ Pro and any USB DAC
      http://kb.roonlabs.com/LinuxInstall

      or a Hifiberry Roon image that I am sure would have no issue with a USB DAC too.
      https://www.hifiberry.com/build/download/

      Delete
    2. Yes. I have measured the Pi3 / Roon Bridge endpoint already using DietPi for a very clean install.

      That will be forthcoming. Hint - it's good :-).

      Delete
  2. Thank you very much Archimago! I really appreciate you answering to a "nobody". I also liked the humor.

    On another note, you've saved me so much money and have given me peace of mind when it comes to cables, bits are bits, and USB Audio. I really hope karma exists, because you have bucket loads of good karma coming your way!

    Thanks again,

    JX

    ReplyDelete
    Replies
    1. Hi JX. A pleasure man.

      I don't know about the karma part :-). But doing this is also just as much for my own peace of mind and satisfying my curiosity after years of being an "audiophile" with the usual ideas promoted out there.

      With the advent of easy access to knowledge on the internet, ability to connect with others for ideas and tips, as well as technology available including inexpensive hardware and open software, the time has come that we can find answers ourselves when it comes to mature technologies like audio. Not just on the level of "give it a try" as some would advocate - it's impossible to try everything! Rather on a more fundamental level of "objective truth" beyond experiential idiosyncrasies and subjective biases. To understand WHY things are or are not and have the data to back up one's position with clarity of mind.

      Glad to share the peace of mind. Cheers.

      Delete
  3. Another excellent article, Archimago! I really enjoy reading your articles.
    Quick question: did you measure and compare the RPI with and without the CRAAP? Or is CRAAP just crap :-)

    ReplyDelete
    Replies
    1. The measurements I showed are *stock* Pi 3. None of those are with the CRAAP optimizations. It only gets better with CRAAP... :-)

      Delete
  4. Arch,
    Nice job.
    I don't use a Pi but I do employ a NUC/JRiver/Dirac.
    Would the CRAAP parameters apply to this configuration as well?
    thanks,
    sk16

    ReplyDelete
    Replies
    1. Hi sk16.

      No, you will not be able to use the CRAAP settings. Those are specifically for the Raspberry Pi 3. When the Pi computer boots Linux, it uses those default configs sort of like how the BIOS or modern UEFI applies overclock/voltage settings in the PC world.

      (Seriously though, no worries - the NUC is awesome as is!)

      Delete
  5. Another great test Archimago!
    So... I definitely think that something is wrong in my setup...
    In comparing a HP x2 1011 with JRiver versus the Pi running MPD, I get good results just with 16/44... anything with higher resolution is poor on my Pi.

    ReplyDelete
    Replies
    1. Curious, what software are you using for the Pi? Is it a Pi 3 with one of the common packages like Volumio, RuneAudio, Archphile or is this a generic install you have of MPD?

      I've tried Volumio and RuneAudio extensively over the last few months (ODROID-C2 earlier this year, and last 3 months Pi 3). Hi-res no problem at all and sounds great. Hi-res should not be an issue at all compared to a Core M hybrid HP.

      Delete
  6. Just swapped over a config file from a piCorePlayer setup with your tweaks over to a Max2Play setup seems to work ok

    ReplyDelete
    Replies
    1. That's great. Essentially all Debian-based OS'es for the Pi should use configs like this. I can also say that DietPi, with which I run my Roon Bridge has the same configuration system.

      Delete
  7. Hi Archimago, very helpful in depth analysis, this is the type of test I was looking for!! No commercial magazine will ever publish this type of article, thanks a lot for your work, so much appreciated

    ReplyDelete
    Replies
    1. Enjoy the music Fabrizio!

      You got to wonder though given the obvious interest in this post and number of hits I'm getting on this from around the globe... Why are the commercial magazines *not* running tests and articles on topics like this which obviously interest audiophiles and computer audio enthusiasts?!

      Delete
    2. I'll bet its got something to do with "Money".

      Delete
    3. I wouldn't bet against you Cut-Throat :-).

      Delete
  8. CRAAP™
    VAAGUE™
    and Dunning-Krugers like WindowsX taking it seriously :)
    LOL

    ReplyDelete
  9. Thank you for sharing your data. Have you looked at the effect of using the kali card in your rpi stack? This is a buffer that intends to re lock the i2s signal.

    ReplyDelete
    Replies
    1. +1. I recently purchased the Kali + Piano 2 DAC and this sounds better to me than the Hifiberry DAC Plus Pro. It would be great to in/validate this subjective impression with measurements.

      I would also like to understand why an external reclocker would be theoretically better than a DAC board which has a built-in clock. Allo claims that the clock crystal in the Kali is somehow superior.

      @archimago - your thoughts?

      Delete
  10. Someone on the Volumio forum said that the Pi USB is "on-the-go" type and does not support reliable asynch USB protocol. All I can say to that is - I am glad I came across this post from you :)

    ReplyDelete