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 computerFor 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. RightMarkFirst, 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. JitterHere 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.
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!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):
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!
to the "# uncomment to overclock the arm" part so it looks like this:arm_freq=800
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!):
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.
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
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 DACDelete
or a Hifiberry Roon image that I am sure would have no issue with a USB DAC too.
Yes. I have measured the Pi3 / Roon Bridge endpoint already using DietPi for a very clean install.Delete
That will be forthcoming. Hint - it's good :-).
Thank you very much Archimago! I really appreciate you answering to a "nobody". I also liked the humor.ReplyDelete
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!
Hi JX. A pleasure man.Delete
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.
Another excellent article, Archimago! I really enjoy reading your articles.ReplyDelete
Quick question: did you measure and compare the RPI with and without the CRAAP? Or is CRAAP just crap :-)
The measurements I showed are *stock* Pi 3. None of those are with the CRAAP optimizations. It only gets better with CRAAP... :-)Delete
I don't use a Pi but I do employ a NUC/JRiver/Dirac.
Would the CRAAP parameters apply to this configuration as well?
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!)
Another great test Archimago!ReplyDelete
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.
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?Delete
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.
Just swapped over a config file from a piCorePlayer setup with your tweaks over to a Max2Play setup seems to work okReplyDelete
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
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 appreciatedReplyDelete
Enjoy the music Fabrizio!Delete
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?!
I'll bet its got something to do with "Money".Delete
I wouldn't bet against you Cut-Throat :-).Delete
and Dunning-Krugers like WindowsX taking it seriously :)
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
+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.Delete
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?
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
Honest question, from what I can see I would NOT hear a difference between a straight Pi and a Chromecast Audio correct?ReplyDelete
Thanks for putting to bed another potential cause of audiophilia nervosa, Archie. I've been using a RPi 3 as a Roon Bridge for months and it sound great. Reading all the hype elsewhere about the likes of the Micro Rendu device (plus expensive psu) does rather baffle me when you can get essentially bit-perfect performance for a fraction of the price with a Raspberry Pi.ReplyDelete
Good thing you're here to fight the good fight and edumacate those willing to listen. Please keep it up!
Excellent blob posting. Thanks so much for your knowledgebase.ReplyDelete
Until reading this post I had believed my Dragonfly Black sounded better on my MacBook Pro than on the RPi 3. Do you think it would be worthwhile for me to move my media from one of the RPi USB ports over to a network device? Perhaps running multiple USB devices is a problem? (I'm running Volunio and use an iFi power supply btw) Thanks!ReplyDelete
Very nicely articulated.ReplyDelete
Fantastic post, thank you! Look forward to your DietPi measurements for Roon as an endpoint since that's what I use at home. But I would LOOOOOOVE to see this articles implementation, or the future DietPi implementation compared to a Sonore microRendu or ultraRendu. I'd bet dollars to doughnuts there's no improvement with spending 20x the cash. But I'd love to see it proved. Judging by the mass histeria across multiple forums in response to Amir showing the iFi Regen does nothing, you'd get lots of hits showing the Rendu doesn't do anything a Pi can't do...ReplyDelete
Greetings! I'm sure the DietPi is serving you well these days. Alas, since I don't have Roon still, unable to measure for the moment... Of course I don't anticipate the new version of Roon to make much difference compared to this a few months back:
So much hub-bub being made about basically low power SBC machines like *Rendu. IMO the sonic claims are just hot air with no evidence at this point that the theories around noise or timing/jitter are of any significance. The guys advertising are free to say what they please (so long as not outright fraudulent claims if they know for a fact that they're promoting lies)... As consumers, we need to be wise and make sure to our engage critical thinking skills of course.
I stumbled upon your blog after Googling for some online evidence to support the claims of a certain YouTuber from the Netherlands. Very insightful and relevant. Thanks.ReplyDelete
After reading your article my Raspberry Pi 3 plus IQaudIO DAC+ RoonBridge now sounds so much better. I'd go as far as saying that my music has more energy. It's like having a workout in 0.376g! :‑J
In all seriousness, the nub of the problem is that those with a tendency to CRAAP wouldn't admit that a £100 investment can possibly sound as good as it does. I'm sure they would sound so much better they came in black anodised cases!
Yup, black anodized, one-piece aeronautical-grade aluminum :-). Essential!
As usual, we must all consider the evidence or lack of it and come to terms with what we choose to believe. While I have no doubts that the hobby will always have those *desperately* desiring to eek out the very last drop of performance (or what they might view as improved sound quality no matter how unlikely), hopefully as a group, "audiophiles" will be more rational over time... Learning to be satisfied when thresholds of audibility have been reached and indeed exceeded by reasonably priced devices.
I was wondering what the CRAAP settings for Pi2 would be, given the slower CPU/GPU speed. What do you think about the below settings?ReplyDelete
CRAAP settings fro RPi 2 (beta)
# gpu_freq=300 (as it's already slow enough at 250 MHz)
over_voltage=-4 or -2
over_voltage_sdram=-4 or -2
I'll test it shortly as my Digi One has arrived yesterday.
How'd it go? I have a Pi2 that I'd like to optimize. It's running ropieee. Would your settings still apply?Delete
Al! Very interesting but puts me in mind of the early days of cd when a lot of the big manufacturers insisted that they all sound the same because they all measure the same, but anyone who actually listened to them could hear huge differences. I built an elaborate linear psu to power a cheap dac after noticing huge differences with two different types of switched mode psu. I got a third party to do an A/B test without telling what was going on and it was as evident to them as it was to me that the linear psu was by far the best even though it was 6 times the size of the dac.ReplyDelete
Thanks for the useful CRAAP. :)ReplyDelete
I just bought a pi3 and it's feeding my Arcam rDAC over USB, with a Jitterbug in between. Running Roon on a PC and RoPieee on the pi. Sounds good but looking to make improvements.
I've read an argument that the pi2 will sound better because the pi3 has WiFi and Bluetooth, which will cause noise... Any thoughts on that? Or can those be completely turned off?
I find that under voltage gives me muddy bass. Anyone else share the same outcome?ReplyDelete
craap really works. thxReplyDelete
Thanks for sharing this great post. It is very enlightening. I absolutely love to read informative stuff. Looking forward to find out more and acquire further knowledge from here! Cheers
5 Wire Resistive Touch Screen
Any value to doing the CRAAP or other tweaks on the pi 4?ReplyDelete
I just apply it on RPI4, it works :) ;)ReplyDelete