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 (EDIT: I previously made a mistake - it should be over_voltage_sdram as below):

arm_freq=800
sdram_freq=400
core_freq=400
gpu_freq=300
over_voltage=-4
over_voltage_sdram=-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! [Update - November 2017: These days I only underclock by -2 for both CPU voltage and RAM. I noticed some instability in the summer heat so decided to tone it down a little; YMMV.]

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.