Saturday, 20 May 2017

MEASUREMENTS: Raspberry Pi 3 "Touch" music streamer

The music being played is the soundtrack from Japanese anime Your Name (Kimi No Na Wa). Saw it with the family last week - great flick!
A few weeks ago when I described the building of the Raspberry Pi 3-based music streamer with touchscreen (I'll just call it "Pi Touch" in this post), I promised that I was going to publish some measurement results.

Well... Let's have a look at those results! :-)

Remember that the measurements in this post will be built upon what we know already about the quality of the Raspberry Pi 3 as USB streamer to my TEAC UD-501 DAC and also the analogue output from the Pi 3 with the HiFiBerry DAC+ Pro. Please have a look at those posts for descriptions of sound quality and subjective impressions... This post is about finding objective change.

For completeness if anyone is wondering, here's the "Pi Touch" with the inexpensive switching power supply I'm using (it's the US$8 Enokay 5V 2.5A power supply - convenient with a push-button switch you see on the left):

The measurement set-up is very simple...

For analogue output (HiFiBerry DAC+ Pro, Squeezebox Touch):
Device being tested --> 6' generic RCA --> Focusrite Forte ADC --> 6' generic USB --> Windows 10 laptop
For digital output (USB):
Device being tested --> 6' generic USB --> TEAC UD-501 DAC --> Focusrite Forte ADC --> 6' generic USB --> Windows 10 laptop
The "Pi Touch" device had the screen brightness up at level "50" (unless otherwise indicated) using the latest version of piCorePlayer available currently (3.20 Normal Version; the "Audio optimized" version seems to not recognize the touchscreen properly for changing brightness in Jivelite). I made sure the screen stayed on with the "Currently Playing" album cover displayed during testing. These measurements are made with default piCorePlayer configuration settings, not the CRAAP tweak :-).

The Squeezebox Touch was updated with the EDO (Enhanced Digital Output) plugin that allows output to 192kHz with the custom kernel. The TEAC UD-501 I believes uses the Tenor (TE8802L?) USB chipset so you need to use the Triode Kernel #12 to get it working - check out this "how-to" page to get it working.

Below, you see the simplicity of this testing setup with both the "Pi Touch" and an actual Squeezebox Touch connected over WiFi to my Logitech Media Server machine in the basement, playing various test tracks. Obviously to get the touchscreen working on the "Pi Touch", I activated the Jivelite interface in piCorePlayer. On the computer screen is the FFT of the 24-bit jitter test probably from RCA output of the SB Touch based on how the cables are arranged. Very straight forward test of the analogue outputs from these devices. Remember that the Focusrite Forte can run completely USB-powered off the laptop which makes it convenient that I don't need to have the computer or ADC plugged into the wall. This also reduces or removes 60Hz AC hum in the measurements.

And here's what the devices looked like hooked up to the TEAC UD-501 DAC for testing USB digital output:

A. RightMark test results

Remember that these tests are mainly to see if the "Pi Touch" device with the official Pi touchscreen assembled in the case affected the already excellent objective results from a basic Pi 3.

16/44 (Analogue output from HiFiBerry DAC+ Pro):
Starting with standard CD resolution as usual...

What you see is the output of the "Pi Touch" using the HiFiBerry DAC+ Pro analogue output in the first column. This is followed by the actual Squeezebox Touch analogue out, then the Pi3-HiFiBerry DAC+ Pro without touchscreen, and finally on the right for reference my TEAC UD-501 DAC fed by a Windows 10 Surface Pro 3 computer using TEAC's ASIO driver that I have been using for years to represent a more expensive desktop DAC system.

Here are the graphs:

What's pretty obvious is that 16/44 poses no challenge for any of the devices really. We see that comparatively the old Squeezebox Touch has higher noise in the low frequencies; especially more 60Hz hum than the others. However, the HiFiBerry DAC+ Pro as I had shown before has a bit more IMD+N.

Notice that the touchscreen interface made no substantial difference to the measurements compared to the Pi 3 + HiFiBerry without touchscreen and the Jivelite GUI interface running.

16/44 (USB digital out to TEAC UD-501 DAC):
Likewise here are the measurements for USB digital output from the "Pi Touch" to the TEAC UD-501 DAC:

As you can see when you communicate with the digital USB asynchronous interface, what you end up with is "bitperfect" transmission and timing parameters inherent to the DAC itself... Clearly evident in the graphs:

Not only is 16/44 no big deal these days, but when using the same DAC, the graphs are essentially exact overlays of each other.

24/96 (Analogue output from HiFiBerry DAC+ Pro):
Here we go into the hi-res territory of 24/96...

Notice that in this series of tests, I wanted to see if the screen brightness made any difference to the measurements. With a 24-bit signal, we want to make sure no extra noise is affecting the output.

The 25% and 100% designations indicate just how bright I made the screen in the settings using Jivelite. Audiophile "common sense" might suggest that the higher the brightness, the more "noise" there should be, especially when measuring the analogue output from the HiFiBerry DAC+ Pro HAT board situated behind both the Pi 3 motherboard and the LCD touch screen of set brightness.

Well, numerically we see no evidence that there's much if any noise difference between 25% and 100% screen brightness; only 0.2dB difference in the noise level and if you compared with the old "Pi3 - HiFiBerry DAC+ Pro" results without the touchscreen (which was measured months ago), there's barely any difference to report.

Here are the graphs again:

Notice the frequency response graph is zoomed in to show the variation between devices in the high frequency roll-off. Very little difference down <1kHz.

24/96 (USB digital out to TEAC UD-501 DAC):
As for the digital USB output between the devices:

Again, we see just how robust the asynchronous USB interface is! There's just no measurable difference between the devices feeding the TEAC UD-501 whether it's the "Pi Touch" with screen brightness at 25% or 100%, the old Squeezebox/Logitech Touch with EDO plugin/kernel, or the Microsoft Surface 3 feeding the TEAC UD-501 with ASIO.

24/192 (Analogue output from HiFiBerry DAC+ Pro):
Finally, let's just have a look at the 24/192 test. As usual, RightMark messes up some of the graphs but I can at least show the frequency response and noise floor measurements.

First up is the analogue output with the HiFiBerry DAC+ Pro compared to others. Note that there is no Squeezebox Touch in this series because the internal DAC maxes out at 24/96:

Again, I have comparisons of the touchscreen at 25% and 100% brightness, then there's just the Pi3-HiFiBerry combo without the touchscreen/Jivelite, finally on the right is the Surface computer feeding the TEAC DAC via USB.

No significant difference between 25% and 100% brightness. In particular I don't see any unusual noise issue. In fact the TEAC shows a couple of noise spikes around 120 and 180Hz in the noise floor not found with the HiFiBerry DAC+ Pro output.

24/192 (USB digital out to TEAC UD-501 DAC):
And as for feeding digital signal to the TEAC DAC using the different devices through USB (Squeezebox Touch with EDO kernel supports 24/192 USB digital output):

Yet again, asynchronous USB simply "works"; no significant difference in the numerical results nor in the graphs. Again, no evidence of extra noise from the touchscreen between 25% to 100% brightness across the 96kHz audio bandwidth.

B. Jitter

Here's the J-Test with the HiFiBerry DAC+ Pro HAT attached to the "Pi Touch" device:

Now with the "Pi Touch" sending asynchronous USB out to the TEAC UD-501:

Obviously there is no worry at all about jitter being a problem! You can see the low level 16-bit jitter modulation signal with the TEAC UD-501 better because it has a lower noise floor (higher resolution).

In fact, I'll even show you the J-Test result with the Squeezebox/Logitech Touch feeding the TEAC UD-501:

Again, that's simply beautiful and a nice demonstration of the ability of asynchronous USB in terms of its ability to reject jitter!

Want to see some jitter, though?

Notice the difference when we connect that same Squeezebox Touch to the TEAC DAC but using a 6' coaxial S/PDIF cable instead! Clearly, we can see the effect of jitter and the effect of the temporal inaccuracies in the S/PDIF system. Remember that although this is easily demonstrable, I would not put any bets on blind-testing audibility!

C. A Closer Look At The Noise Floor

As suggested above with the 25% and 100% RightMark tests of screen brightness, there was no evidence that the screen added noise. For completeness, I wanted to have another look using a higher resolution FFT playing a "digital silence" track through the HiFiBerry DAC+ Pro HAT board while the screen is displaying an album cover at various brightness levels. Remember, the HAT board is just attached right behind the Raspberry Pi 3 motherboard and in quite close proximity to the touchscreen.

As you can see, there's no evidence of noise whether the screen is off at 0% brightness, dim 25% or bright 100%. Note that the 37kHz noise is from the Focusrite Forte ADC and not from the Pi 3 device.

D. Conclusions...

Well, there you have it. The "Pi Touch" device sounds great already and the objective results simply confirm what I've been hearing from this device with a touchscreen LCD grafted on and using UI software (Jivelite). Remember too that I'm just using the inexpensive US$8 switching power supply, no fancy USB reclocker, no expensive linear power supply, and simply generic cables. In summary:

1. The analogue output from the HiFiBerry DAC+ Pro is as measured previously. No evidence that the addition of the touchscreen affected the sound quality. No evidence that increasing screen brightness adds any extra noise or causes sonic deterioration. Compared to the original Squeezebox Touch, the HiFiBerry DAC+ Pro has lower noise floor, less stereo crosstalk, but a bit higher intermodulation distortion.

2. Digital output through USB to an asynchronous DAC (the TEAC UD-501) is free from jitter and measures just as well as other devices. Subjectively and objectively, I have no reason to believe that a digital source changes the sound through a good asynchronous USB DAC. I realize that this statement is in contradiction to some articles claiming otherwise - such as this one. I am basing my opinion on the measurements above plus my own experiences over the years... I would certainly like to see some objective evidence from those making the opposing claims.

3. Remember that whereas asynchronous USB can be free from jitter, S/PDIF interfaces (TosLink, coaxial) are generally not. This is I think nicely demonstrated above comparing USB output vs. coaxial cable with the Squeezebox Touch to the TEAC DAC. This is contrary to some opinions I have seen that because USB is a "general" computer interface, it is somehow "bad" for audio. Nonsense. A good asynchronous DAC will be able to handle noise and provide better time domain output with USB in my experience.

As a point of comparison, the old Squeezebox Touch coaxial S/PDIF seems to be a little more jittery than the Chromecast Audio's TosLink output at 16-bits but better at 24-bits.

One last thing... How much CPU is being used with the "Pi Touch" when streaming high-resolution music while the Jivelite user interface is running?

As you can see, it's 3.7% here while streaming a 24/88 track over ethernet from the Logitech Media Server computer in the next room. In fact, 3.7% is on the high side. Most of the time the CPU usage is around 1.5-2% with 24/88 and 24/96 music. With 24/192, I see CPU utilization hovering mostly around 3%. Needless to say, the Raspberry Pi 3 isn't particularly strained with piCorePlayer and Jivelite running! This means there's plenty of CPU cycles available for other things which we'll talk about another time :-).


Okay folks... As I said last week, life is busy :-). Having said that, I have been sitting on these results and just had to get them out since it has been a few weeks already since the previous "HOW-TO" build article.

Other than the "High End Munich 2017" show this week, in audio news recently, I see that MP3 has finally been deemed "patent free" as of April 16, 2017 (although formally there is this one that runs through to Dec. 30, 2017). Well, finally open-source software like Linux distributions will be able to have full releases with MP3 capability now that IIS Fraunhofer/Technicolor have terminated their licensing program ("Full MP3 support coming soon to Fedora"). Certainly nice to have the convenience now of full functionality included in the Linux distros.

This is good news right? It is fascinating the perspective however from the side of the rights holders. For example, check out this title from Billboard magazine - "The MP3 is Officially Dead: License Terminated by Developer"!

Well yes, the licensing program might be "dead", but IMO MP3 itself is as alive as ever :-). Of course license holders want to steer the industry to use file formats with extant licensing agreements. Sure, the newer lossy formats may be "better, [with] lower-bit files", but it's not that much better by the time we're looking at 256kbps and above. Remember the MP3 blind test done here years ago suggesting that MP3 ~320kbps was transparent (and might even be subjectively preferred by some!) for music compared to lossless 16/44.

I think we can look at JPEG as an example of how an old, lossy format continues to thrive today as the most used compression standard for 2D images (JPEG patents expired by the end of 2006). Despite technically superior contenders like JPEG2000 or BPG, good 'ol JPEG is going strong and remains essentially unchallenged. So too I suspect will be the fate of lossy audio encoding... There's just no compelling need to change. MP3 is not dead, and in fact it has just become stronger as the de facto, now free, and universally compatible lossy audio format for the foreseeable future.

We should all remember the contributions of open software developers, especially those who worked on LAME, in maturing the code and advancing the psychoacoustic tuning.

Hope you're all having a lot of fun with the audio hobby!


  1. Another great article!
    I have a Toslink vs USB question that I hope you can shed some light on. Your comments about jitter have spurred this question.

    I'm feeling that I will soon need to replace my beloved Squeezebox Touch, solely because changes at the Spotify service are slowly crippling the Triode 3rd party Spotify plug-in. Many days I can't get the Touch to load my current Spotify playlists, and sometimes it hangs forever while trying to read-in playlists. At other times it mysteriously performs fine but over time it is getting worse. The "official" Spotify LMS plug-in is unacceptable because it does not support the Spotify folder structure for playlists, which I make extensive use of.

    I'd like to get a device that lets me play the folders from my local server AND supports Spotify Connect. With Spotify Connect I would not be relying on 3rd party support, especially as Spotify makes the inevitable changes needed to offer lossless streaming.

    The thing is, all of the devices that seem like viable replacements include only Toslink for digital output. My EDO-modded Touch sounds quite a bit better using USB vs Toslink or S/PDIF. I don't know if the poorer performance is because of the sending unit in the Touch, the receiver in the DAC, or if it is caused by jitter - but it's definitely noticeable. USB is the way to go. Based on your comments about jitter, it seems I might be making a huge step backwards going to a device that offers only Toslink.

    What do you think? Are some Toslink interfaces better than that of the Touch? (And why, in this day of tremendous USB DACs, do so many devices have only Toslink?)

    (The most appealing option is the Bluesound Node 2 because it offers features very much like the Touch - folder-based access for local files, gapless playback, hi-res streaming, and it adds Spotify Connect. Also, the Bluesound Android control app integrates the local player with Connect to let one create cues/playlists mixing local and cloud content. The only thing missing USB output. The Bluesound company seems established and "in it" for the long run, so hopefully support and updates would be solid. Of the two "high end" options out there, the Sonore microRendu has no WiFi, a deal breaker, and the Auralic products have no Spotify Connect and their control app requires iOS, another deal breaker.)

    On the other side of the coin...

    Is it feasible to build a satisfactory device around a Raspberry Pi? I have read that Volumio supports Spotify Connect but It is not at all clear how that works, or how it integrates with playing local files. And I really don't want to get in a situation again where support for the Spotify integration lags behind changes that the Spotify service makes. I know you run piCorePlaer instead of Volumio but I'm hoping maybe some of your readers have experience with viable options and might respond. I have no interest in making the tech side of this into a hobby (music listening is my hobby) but I do have some computer skills, and a good friend who is a Linux expert, so if the Pi seems like a good option that can offer completely reliable playback, I might be willing to tackle it. The low cost is certainly attractive too.

    1. Hi Mark, some really good questions there...

      First I think when it comes to Spotify Connect & Volumio 2, have a look at "volspotconnect" plugin. Check out the video:

      Since I don't use Spotify other than as a free user when I'm jogging these days, I'm afraid I don't have this connected to try.

      Now as a tech guy, I might persevere to get Spotify running but of course for the folks who just want to set it and forget it, this might be too much hassle. Plus even if it works now, it doesn't mean Spotify will not change the SDK over time and one would have the hassle of reconfiguring :-(. Probably best to stay with an officially supported option.

      As for the different digital outputs, yes, different S/PDIF interfaces will result in different output qualities. Assuming there is no data error, the timing will be slightly different; tiny differences in the frequency response charts for example. Also of course there will be jitter differences which the asynch USB system will for the most part be immune to.

      S/PDIF remains popular and cheap. Another nice thing about S/PDIF is that it's unidirectional - eg. the light goes from one device to another, no special handshaking, easy to implement. You can plug and unplug without the DAC complaining whereas with USB it knows something is disconnected. Plus in USB there is driver compatibility. The better TosLink devices (including the Touch in my experience) can also handle 24/192 although the majority goes up to 24/96. Remember that it is more important with TosLink to have a decent cable especially for hi-res data because it isn't as robust as coaxial (shouldn't need to spend >$50!).

      The other day I was at the local dealer listening to the Bluesound Node 2. My friend was interested. It sounds good and does have MQA for those who want it. I played around with the box's Tidal streaming on an Android phone. Worked well.

    2. Thanks Archimago, some really good answers there...

      I can be pretty techy myself, and am usually successful at getting things working. I will even admit to enjoying the challenge. But music listening is my main interest and anything that disrupts that is pretty annoying.

      Special thanks for your comments on the Node 2. I am hoping to be able to check one out locally.

      It's good to know that Toslink performance responds to decent cables. But just what is a "decent cable"? Is plastic optical fiber better? Or glass? Or is glass too fragile? Single strand or multi-strand? Thin and flexible or multi-layered and stout? Polished connector ends vs triple-polished connector ends? Some give the impression that they have special properties to block electrical interference (yah, they are optical!) Others have gold plating for a better connection (they're optical, aren't they?)

      Keeping to your <$50 recommendation, and my desired 0.5 meter (18 or 20 inch) length, I find that Audioquest has a multi-strand model for $39 (although it is a slightly-too-long 0.7 meter). Blue Jeans Cable (many have good things to say about their sensibly-priced products) will hand build one for only $11.75. Wireworld's single fiber model is $35, and Straight Wire's hefty-looking 0.6 meter model is $38.

      Stretch to $61 and Kimber uses "medical grade" fiber. And Lifatec replaces the usual molded plastic connectors with precision machined metal at $75.

      All claim excellent performance and maybe every last one would beat my $6 generic model.

      So what's "decent"? Do I buy based on hype? Or color preference? (the green Audioquest.) Cost? (the Blue Jeans.) Coin toss? Buy the whole bunch and throw out the ones I don't like? As one might expect, Googling "best Toslink cable" got me a lot of very skeptical advice. Any light (pun intended) you can shed on this would be greatly appreciated.

  2. Off topic ...
    Qobuz has launched his Hi-Res service (
    I have checked "blue in Green", 24/96.
    The downloaded size is 114,739 KB, 2797 bitrate. A previous 24/96 version I have is 106,836 KB, 2614 bitrate.
    I guess th's not MQA ...

    1. Interesting Teodoro.

      I checked out the website, doesn't look like they say anything about MQA so I'm sure it's not. Plus the MQA folks would be telling us all about it if another streaming site other than Tidal went online with it! :-)

      FAQ describes it as FLAC compressed hi-res lossless up to 24/192. Looks like it's the "real deal"!

      Assuming the mastering is the same with your 24/96 copy, maybe for streaming they used a lower level of FLAC compression? Slightly higher bitrate but easier decompression for some of the lower CPU power compatible streamers?

  3. Hi.
    I like you blog very much but i have a question.
    I'm usnig raspbery pi 3 and audioquest Dragonfly black DAC streamning from network NAS.
    Is there any difference in audio quality using wireles or wired connection?
    There was some noise problem in older versions of Pi?


    1. Hi Dodo,
      I have not seen any significant issues between WiFi and ethernet that I would care about or feel is audible. There is a *very* slight 60Hz hum over ethernet system in my network setup as demonstrated here:

      That's likely from the 60Hz A/C here in North America. It's way down <100Hz.

      Noise in older versions of Pi? I don't know since I only jumped on board with this last year and have only the ODROID C2 and Pi 3. Both of which no issues with noise. Your Pi 3 + Dragonfly Black should sound great!

    2. Hi. They were talking about raspberry pi using ethernet and usb on same chip or chanell, i dont know now for sure.
      But it sounds good on both so it's ok :)

      thx for reply.

  4. Hi Archimago, the Asus Tinker Board was released a while ago. The folks at Volumio have quite a positive review on this new toy

    Do you have any intention to measure Tinker BoArd?

    1. Interesting SYM.

      However I must say that the RK3288 SoC with Mali-T764, while great for audio streaming, is in many ways behind even something like the ODROID-C2 which has 64-bit quad core, decent hardware 60fps 4K decode of 10-bit HEVC a year ago. The only thing the ODROID-C2 is missing is built-in WiFi.

      I'd love to see ODROID come out with an updated C2 featuring the S905x SoC for HDR 4K, integrated WiFi, integrated Bluetooth, and maybe broader HAT board compatibility for DACs and compatibility with the Raspberry Pi touchscreens. It already has gigabit ethernet which works well!

      As for the Tinker Board's 24/192 DAC... Hmmm, I'd like to see measurements as well. Until proven otherwise, I suspect the quality would not be great.

  5. great review as usual.

    Unfortunately I am working aroud Raspberry and hires flac since months without good results :-(

    I hope you, and other people following this blog, can help me in finding where I am wrong.

    I started years ago with a headeless mini-PC running Ubuntu + pure MPD + M2Tech HiFace usb DAC and using a tablet to control it.
    The results were absolutely great, even playing very high resolution flac (384 kHz)
    I am able to get the same good results with a Windows 10 touch PC (HP x1011) running JRiver.

    Then I started to play with the Raspberry Rpi3 as soon it was available.

    Rasp + official Raspbian + pure MPD + same USB DAC: perfect results, both with WiFi and wired Eth.
    Same as above buth Volumio: again perfct

    the nightmare begins adding the official Raspberry touch LCD...

    Volumio with the LCD touch is terrible: anything @ 96 kHz or higher produces a lot of pops, glitches, spikes, etc.
    Then I switched to piCore Player (without Jivelite for now), installing everything, including the LMS on the same raspy.
    using the Wired Eth sounds very good, switching to WiFi... again a lot of noise playing high res flacs.
    Upgraded to 3.20... no improvements.
    Since I do not have an external LMS, I then installed Logitech LMS on a windows PC, but the sound quality did not improved.
    Loading Jivelite and enabling the LCD was even worst: noise not only with WiFi but even with wired Eth.

    The best results I can get from running RuneAudio with wired Eth.: perfect sounds, but again lot of noise with WiFi.

    Assuming a problem with my raspy (made in Asia), I got another one made in UK, but results are the very same.

    Any idea why these very poor results?

    1. Hi Sonus.Faber...

      Interesting. So just to be clear, suppose we use the piCorePlayer example which I am most familiar with. Without using the touchscreen, and using wired ethernet, it's good. But switching to the WiFi it sounds bad?

      And this is using LMS on a Windows PC - is that PC wired to the ethernet or also WiFi?

      What router?

      Is the signal strength to the Pi good? Are you streaming 16/44? (Remember that the Pi does not have a very strong WiFi radio transmitter so be careful with hi-res.)

  6. Focusing on piCorePlayer, with the LCD touch and Jivelite, I always get noise (pops, spikes, scratches...) no matter wired ethernet or WiFi. IF I load my test flacs on a USB memory directly connected to the raspy, so without using any network connection, then I continue to get the very same noise, just to be clear.
    Of course, with the USB memory, the LMS is the one loaded into the very same raspy running the player.
    Anyway, the PC is connected to the wired Gbps ethernet and the NAS too.
    The NAS is an HP Proliant industry server.
    The router (if I involve the WiFi is a Vodafone Station revolution) but anyway the switch is a Netgear ProSafe Gbps.

    In any case, the problem could the WiFi when playing very high res flac, but not when playing 96 kHz.
    having the files loaded from USB memory, I definitely excluded the network...

    For sure it is something dealing with the LCD touch interface \ Jivelite, since the very same problem rises with Volumio.

    Just for your information, I tested the same raspberry Rpi3 + official Raspbian + pure MPD with some 32 bit \ 384 kHz (the highest sample rate my USB dac can manage) and again it is perfect.

    I am not alone

    1. Interesting... I'm not hearing such a problem with my system. In fact I've even streamed upsampled 24/384kHz stuff to piCorePlayer with the TEAC and up to 768kHz to Oppo Sonica DAC through the Pi 3 without issue WITH Jivelite active. I've even underclocked and undervolted the system with no issue.

      Also just to clarify, are you using the official Pi 7" touchscreen? Also what case/enclosure are you using? Not that it necessarily makes a difference but curious...

      Also for sure you're using a power supply with 5V/2.5A current capability so power is not an issue?

    2. Yes, I am using the official Pi 7'' LCD.
      At the moment, no case at all. It is assembled "open air".
      I tested several power suppliers and I am using the official 2.5A one.
      I tested also two of them: one connected to the mainboard and the second one to the LCD board, without any audible difference.
      I measured the voltage on the Rpi3 with a digital sampling Fluke multimeter (a 600 $ Fluke unit) and I can not see voltage drops (2 ms sample interval).

    3. I solved the problem, thanks to the help of people in the SlimDevices forum.
      I enabled the "TURBO MODE" on my Rpi3 and the noise... disappeared!
      Now I can play my FLAC up to 352 kHz @ 24 bit!!!

    4. Cool sonus.faber,
      Curious what's the reason behind this need to overclock?

      BTW, for those interested, here's an interesting article on Pi 3 overclocking:

      Also, which version of piCorePlayer are you using? I've just stuck with the standard version rather than the audio optimized version.

  7. I'm using the official RPi 7" display with the same case. I'm also using a generic 2.5A supply. Audio output is via USB audio to a Cambridge DACMagic+. I've had no problems with noise, in fact it works marvelously, up to and including 24/96 source material.

    I love having access to the music from a console in my listening area rather than using my iOS devices as well as being able to distribute to other audio systems in the house using other RPi/DAC streamers also running piCorePlayer from an LMS installation on my iMac.

    There is a fix for the brightness. This can be fixed by loading an extension, backlight-4.9.21pcpCorePlayer_v7.tcz, that can be found in the picoreplayer sourceforge repository. FWIW, the first time I loaded it, it hosed my Pi Touch configuration completely. Rather than try to troubleshoot what happened, I just reinstalled and reconfigured as it doesn't take that long. I loaded the extension immediately after the basic configuration and Jivelite installation but before installing Shairport Sync or configuring the audio output. I don't know that it made any difference, just being complete about my config sequence.

    1. Update: I found that the Squeezelite Output setting conflicted with the backlight extensions. I was originally using front:CARD=C20, DEV=0. Changing to sysdefault:CARD=C20 worked, but limited sample rate to 48kHz. Using iec958:CARD=C20,DEV=0 seems to be working fine.

    2. Interesting Jim...

      Well, considering that the normal version of piCorePlayer worked with no backlight issue, I don't think I'm going to worry about it. Hopefully the "audio optimized" version gets the screen backlighting fixed for those using the screen.