Back in early 2017, I documented on the building of my little Pi "Touch" music streamer that I've been using over the last while for playback through my Logitech Media Server system at home. Over the last year, I've used this quite a bit for music playback and also some of the testing I've done on this blog.
As some of you may know, there has been an update of the Raspberry Pi 3 to the B+ model (~US$40). The upgrade isn't a major change to the existing Pi 3 board. However the new SOC, based on the Broadcom BCM2837B0 quad-core Cortex A53 (ARMv8, 64-bits) is slightly faster at 1.4GHz (1.2GHz previously, about 15-20% speed gain), and another upgrade is better ethernet speed which supports gigabit link but since it's still communicating through the USB2.0 port, will max out at ~300Mbps. In some benchmarks I've seen, though not true gigabit speed, the throughput is about 2x that of the previous Pi 3. For those interested in wireless connectivity, there are upgrades in the WiFi and Bluetooth departments as well.
The official 7" Pi touchscreen works well with the B+ but there is a new redesign of the SmartiPi Touch case for 2018 because of the small 4-pin PoE header in the new motherboard (cool feature if you have PoE since this will allow the Pi 3 B+ to be powered over the ethernet), preventing the previous case to snap close. I know this because I still use the old case design and cannot close the back plastic flap... So I just left the guts exposed:
 |
| New Pi 3 B+ board inside the SmartiPi Touch case (with the previous Pi 3 B board sitting on the base). Notice the arrow is pointing at the new 4-pin Power-over-Ethernet header. This unfortunately blocks the snap-on cover with the old SmartiPi Touch casing. This is fixed in the new SmartiPi Touch 2018 design. |
Another upgrade I bought recently was the JustBoom Digi HAT S/PDIF board. I was interested in getting an inexpensive S/PDIF HAT board for coaxial and TosLink digital audio output from the Pi 3 streamer. This would make an inexpensive (<US$40) "standard" digital audio output platform for testing DACs. Also, I was simply curious about the digital output quality such as jitter from something like this utilizing a "modern" S/PDIF transceiver - in this HAT board, it's the Cirrus/Wolfson WM8804 released in 2009 and said to have low intrinsic periodic jitter of ~50ps. Remember that S/PDIF (based on AES3) has been around since the dawn of CD audio in the 1980's. This is obviously beyond mature - it's geriatric - as technologies go. The only "feature" I've seen over the last decade is more reliability for higher sample rates like 192kHz through TosLink.
Notice the JustBoom board uses the Murata DA101JC isolation transformer for the coaxial output. And here it is attached to the back of my Pi 3 B+ "Touch" streamer:
Since the S/PDIF outputs are pointing down towards the base, there isn't much clearance which means the cables cannot be thick hose-like snakes! I intend to use the cheapest, thinnest, most pliable TosLink cable I have :-).
Another little upgrade is the power supply:
Nothing fancy. It's a +5V 3.0A microUSB power supply that can handle the whole shebang - the Pi 3 B+ board, touchscreen and digital audio HAT can be used without power warning. There is a power button along the wire leading to the microUSB (can't see as the wire is still wrapped up in the picture). This is convenient to prevent the need to plug/unplug the power to the little Pi whenever you want to turn on/off.
I know, over the years, folks have recommended linear power supplies, upgrades like the BOTW P&P sBooster, and ifi iPower for lower noise and such for hi-fi audio. Alas, I have not actually heard any problems over the years nor seen issues on measurements while using inexpensive switching supplies to power a small device like the Pi for digital streaming purposes to a decent DAC. Remember, last year, I measured the HiFiBerry DAC+ Pro and saw nothing unusual using another switching supply (2.5A supply at that time). This is of course not to say that switching supplies can't cause problems - remember the Tascam UH-7000 from 2015 and how the power supply added noise to the ADC noise floor.
So, "How is the Raspberry Pi 3 B+ machine working out so far?" you ask...
To be perfectly honest, not as good as I had hoped.
I've updated my Pi 3 B+ "Touch" with the latest piCorePlayer 4.0.0 Beta 7 download released August 1, 2018 (notice the new website). While working quite well just as a USB streamer to my Oppo UDP-205 using the original Pi 3 B, despite the potential for gigabit link speed there seems to be a problem with dropouts using the B+ board at this time though my unmanaged ethernet switch. I'm experiencing dropouts and glitches every once awhile even with the older piCorePlayer 3.5 software which also supported the B+. This is particularly bad with hi-res and DSD over WavPack. The realtime kernel version of piCorePlayer did not help.
I did a little sleuthing and noticed that if I installed the "ethtool.tcz" extension and explicitly ran this after logging into piCorePlayer through SSH (PuTTY):
sudo ethtool -s eth0 speed 100 duplex full
Forcing the ethernet down to 100Mbps full duplex, quality improves. No dropouts with hi-res and DSD just as with the previous Pi 3 B board! This suggests that there are issues with the B+ ethernet link speed using piCorePlayer currently. As far as I can tell, it's not an issue with Energy-Efficient Ethernet (EEE). Presumably this will be fixed in future versions of piCorePlayer as it incorporates newer versions of the Linux kernel and drivers? For the time being, you can run the above line as a user command each time it reboots. Remember to install the "ethtool.tcz" extension.
Certainly the solution is figuring out why the B+ isn't communicating smoothly, achieving what should have been improved network speed right out of the box.
Hopefully the folks at piCorePlayer can look into this... If I were buying a Pi 3 these days for piCorePlayer streaming, I'd probably still buy the new B+ board recognizing that for the time being, I'll probably need this hack. I trust that in time with maturity of relevant B+ drivers (Microchip LAN7515 ethernet chip), this should be resolved. Maybe the fix is already out there with a newer kernel/drivers not yet incorporated into piCorePlayer (fingers crossed that this is so!).
One last issue worth mentioning. Remember that awhile back, I talked about intermediate phase filtering and upsampling? Well, now that I'm running my Oppo UDP-205 as the "reference" DAC, as well as the RME ADI-2 Pro FS, I have access to 705.6/768kHz samplerates, so I could do something like this:
Max sample rate:
44100,48000,88200,96000,176400,192000,352800,384000,705600,768000
Upsample SoX setting:
v::4:28:95:105:45
It looks like there is some kind of limitation upsampling to 768000 using piCorePlayer. I was able to get 705600 sounding good with the Pi 3 B(+). However 768kHz is a no-go with both the Pi 3 B and B+ models on both the Oppo UDP-205 and the new RME ADI-2 Pro FS. It sounds a bit noisy with dropouts and especially bad with the Oppo. Since the Oppo uses the XMOS USB controller and RME has their own asynchronous USB design, the fact that 768kHz has issues on both suggest a problem with piCorePlayer or the drivers. Unlikely a hardware issue from what I can see.
Not a big deal since I can't imagine anyone being able to hear a difference between 384000 vs. 768000Hz upsampling :-). But for now at least, a limitation worth noting and I'm curious if this too will improve with future iterations of the piCorePlayer software.
Anyways, looking forward to the final release of piCorePlayer 4.0.0! I do hope particularly that the Pi 3 B+ ethernet issue improves and I don't have to explicitly kick it down to 100Mbps. Do others hear/see this problem with the B+ using piCorePlayer?
-----------------------------------------------
There was quite a buzz recently with the release of John Coltrane's Both Directions At Once: The Lost Album. A reader e-mailed me that he was very disappointed by the 24/192 hi-res download compared to the CD release; check out the DR measurements:
For brevity, I'm showing only CD1. CD2 results look very similar to the above with an overall DR13.CD Release (CD1):foobar2000 1.3.19 / Dynamic Range Meter 1.1.1 log date: 2018-08-14 14:31:06 -------------------------------------------------------------------------------- Analyzed: John Coltrane / Both Directions At Once (The Lost Album) [Deluxe Edition] -------------------------------------------------------------------------------- DR Peak RMS Duration Track -------------------------------------------------------------------------------- DR12 0.00 dB -14.60 dB 5:41 01-Untitled Original 11383 [Take 1] DR14 -0.74 dB -17.01 dB 3:24 02-Nature Boy DR13 0.00 dB -14.62 dB 8:43 03-Untitled Original 11386 [Take 1] DR12 -0.13 dB -14.39 dB 5:33 04-Vilia [Take 3] DR11 -0.33 dB -13.72 dB 4:36 05-Impressions [Take 3] DR13 -2.09 dB -17.43 dB 11:29 06-Slow Blues DR12 -0.28 dB -14.52 dB 8:02 07-One Up, One Down [Take 1] -------------------------------------------------------------------------------- Number of tracks: 7 Official DR value: DR12 Samplerate: 44100 Hz Channels: 2 Bits per sample: 16 Bitrate: 568 kbps Codec: FLAC ================================================================================
Hi-Res 24/192 download (qobuz - presumably the same with other online stores?):
foobar2000 1.3.19 / Dynamic Range Meter 1.1.1
log date: 2018-08-15 17:13:45
--------------------------------------------------------------------------------
Analyzed: John Coltrane / Both Directions At Once (The Lost Album) [Hi-Res Edition]
--------------------------------------------------------------------------------
DR Peak RMS Duration Track
--------------------------------------------------------------------------------DR8 0.00 dB -10.60 dB 5:41 01-Untitled Original 11383 (Take 1)
DR11 0.00 dB -12.97 dB 3:24 02-Nature Boy
DR9 0.00 dB -10.64 dB 8:43 03-Untitled Original 11386 (Take 1)
DR8 0.00 dB -10.43 dB 5:33 04-Vilia (Take 3)
DR8 0.00 dB -9.84 dB 4:36 05-Impressions (Take 3)
DR11 0.00 dB -13.27 dB 11:29 06-Slow Blues
DR8 0.00 dB -10.46 dB 8:02 07-One Up, One Down (Take 1)
DR9 0.00 dB -10.57 dB 4:37 08-Vilia (Take 5)
DR8 0.00 dB -9.81 dB 4:06 09-Impressions (Take 1)
DR8 0.00 dB -10.11 dB 4:38 10-Impressions (Take 2)
DR9 0.00 dB -11.30 dB 3:40 11-Impressions (Take 4)
DR10 0.00 dB -12.18 dB 8:41 12-Untitled Original 11386 (Take 2)
DR11 0.00 dB -12.71 dB 8:23 13-Untitled Original 11386 (Take 5)
DR9 0.00 dB -11.66 dB 7:18 14-One Up, One Down (Take 6)
--------------------------------------------------------------------------------
Number of tracks: 14
Official DR value: DR9
Samplerate: 192000 HzHmmmmm.... We indeed have a problem if this is what they're selling as 24/192 "high resolution" music! Notice the supposedly high resolution version is about 4dB louder than the CD, resulting in limiting of the dynamic range across the whole album with 0dBFS peaks for each track.
Channels: 2
Bits per sample: 24
Bitrate: 3371 kbps
Codec: FLAC
================================================================================
This is the opposite of what I suggested a few years ago about releasing two different versions - an "Advanced Resolution" (AR) version for high resolution with retained dynamics, and a lower dynamic range "Standard Resolution" (SR) version for music meant to be listened to on mobile devices and in the car.
Imagine spending more money on a "hi-res" album, downloading files about 6x the size of 16/44 CD as FLAC, but in actual fact the album is simply louder, of lower dynamic range; essentially of lower resolution where it counts. Seriously folks, this is insanity. What kind of discerning consumer do they expect will want to buy "hi-res" audio like this? Is using the "loudness war" tactic to make the 24-bit version louder supposed to drive sales!? Maybe they just want to purposely tarnish the demand for high resolution? Then again, as per Hanlon's razor - "Never attribute to malice that which is adequately explained by stupidity".
A big thumbs down to Impulse!/Verve/UMG. Disappointing.
September's here. The summer holiday season has flown by. Hope you're all enjoying the music! :-)
Addendum - September 2, 2018:
I see that official piCorePlayer 4.0.0 is out! Great job as always on a remarkably flexible and powerful piece of software, boys!
I checked the data transfer speed of the Pi 3 B+ and it looks pretty good:
As you can see, I'm able to get >240Mbps through the network to the little Pi 3 B+ with gigabit link.
While this is good, I am curiously still hearing imperfections like little clicks and dropouts with hi-res music and DSD over the gigabit link. Again, this clears up with forcing the ethernet down to 100Mbps as reported above. Curious... Wondering if there's some kind of bus contention happening over USB.
Arch, just so you know, cables are now components, according to degreed EE JVS over at Stereophile -- https://www.stereophile.com/comment/578163#comment-578163 I hope you've factored that into your Raspberry Pi set up! (No excuses about lack of space/tight connections. I wanna see some oxygen-free, liquid Vanadium interconnects with an air gap where the cable meets the connector.)
ReplyDeleteHey aonetech,
DeleteYeah, I guess cables are "passive components" :-)
Seriously, what else is someone like JVS going to say, right? After all, the magazine has to maintain an "open mind" about the classes of products being pushed by their advertisers. It must maintain fear, uncertainty, and doubt about the *potential* of jitter needing to be fixed so there is another generation of produce "even better". Likewise it *must* maintain that there is *potential* that air dielectrics and "liquid vanadium" can do something to the final sound... Yes, even to the magnitude of actual active components in the audio chain! Must justify the extravagant price tag which of course one could buy actual active components with!
I guess it's somewhat entertaining reading these opinions...
Once audio gear became as good as hearing, even just one component, an entire industry's survival becomes predicated on denial. This can be kept up for decades,evidently.
ReplyDeleteHey tnargs,
DeleteI think there are many things in this world where shenanigans can be kept up for ages :-).
We love our myths & heroes. They satisfy psychological needs. By I think as time goes on, truth ultimately causes the target audience to lose the faith. This is of course beyond just the tiny sliver of human endeavour like home audio...
Such wisdom! No wonder I eagerly await your every Saturday entry.
DeleteDear Archimago, dear all,
ReplyDeleteI spent a lot of time in the last two years playing with WIndows PC and Raspberry working as streamers.
All the tests have been done with PCM up to 384 kHz @ 24 bit and a Teac UD-503 as DAC converter, togheter with an HiFace DAC.
I think that the problem you experienced with the embedded Ethernet running at 1 Gbps is caused by the
interrupt management of the Rpi3 and its OS ad on Windows the problem is the very same, more or less.
Let me start from Windows.
I setup a brand new HP laptop with touch screen to be used with JRiver on Windows 10.
No wired Ethernet, since it is equipped with WiFI only that can connect at 600 Mbps with my access point
Music is stored on an high performance HP Proliant server.
Server and network, both wired and wireless, are not the bottleneck.
Let me say that installing JRiver on the out of the box PC and playing hi-res music was a NIGHTMARE: heavy audio stuttering.
I tried to uninstall everything from Windows, I disabled every not needed Windows services... no improvements at all even if there were no problems on memory or CPU usage.
Installing on Windows some tools to see the DPC latency... let me to immediately solve the problem.
Each time I see a spike in the network usage, there is a spike in the latency of the DPC and there is a glitch in the output sound.
Forcing the WiFi card to use lower speed, reduced the height of the spike and increased the widht and less glitches.
Forcing 802.11g... solved the problem.
When the WiFi card pulls data from the NAS server, it uses the highest speed and so it is not a costant flow, but we have a spike then no activity then again spike. Each spike is an interrupt. Each spike fills the WiFi card buffer
On the other side we have the audio output buffer. the latency of the interrupt management is higher using higher network speed and it happens that the audio output is emtpy when the network card is still retriving data.
We can also notice a higher CPU usage while transferring the same amount of data at high speed versus lower speed.
Another way to solve the problem was to force JRiver to pre-load the audio file before starting to play. This is possible with JRiver or Foobar, but not with pCP.
I tested other PC, even with wired Ethernet and the problem is the very same.
An high performance PC helps, but does not solve the problem.
I suppose that this is the very same problem we have with Rpi, so this is the reason why decreasing the network speed reduces glitches.
I have a Rpi3 running pCP 3.5 and playing the same 384 kHz @ 24 bits from the NAS:
no problem with wired Ethernet
stuttering using the embedded WiFi
no problem with external USB Edimax WiFi dongle
Thanks for the note sonus.faber,
DeleteI think this could very well be the problem. I haven't spent any more time on the issue working on other things this week...
I wonder if doing a combination of things - throttling the B+ gigabit ethernet, enlarging the audio buffer (no need to fully buffer a track, maybe a couple seconds), changing the priority to favour the USB audio playback system... Might be interesting to see if the pipeline can be optimized to ensure smooth playback of these extreme resolutions.
To be clear, IMO, this is just for fun and to ensure that the system can handle with almost anything thrown at it whether it be PCM or DSD. I'm certainly not advocating for 384kHz music or suggesting DSD256 is needed :-). However, it certainly would be nice to have DSD128 not stutter on the B+ through USB to a DAC on piCorePlayer without kicking it down to 100Mbps.
Are you still using the CRAAP config modifications? If yes, what have you had to change? I tried them, but it won't boot now.
ReplyDeleteIs this qeustion for me?
ReplyDeleteI do not know what is CRAAP. sorry.
Bruce is referring to the CRAAP settings talked about here :-):
Deletehttp://archimago.blogspot.com/2017/01/measurements-raspberry-pi-3-as-usb.html
No, I haven't used any setting for the B+ at this point. Might look into it later...
RE: loudness wars
ReplyDeleteI was recommended this site, and thought folks here would appreciate too, if you're not already familiar with it. The guy explains loudness and dynamic range and the multiple ways to measure it in fabulous detail.
http://productionadvice.co.uk/blog/
What I found most interesting is that all the major streaming services now have automatic loudness limiting. If a music producer pushes the loudness above the streaming service's reference level, the tracks are simply brought down in volume to the reference. It doesn't restore DR, but it takes away the one reason producers had to sacrifice it in the first place, at least on the streaming services. The first few links on his blog are a little click-baity. They're still good, but if you want to jump-in right away just on the streaming services, here's one on a change Tidal made last year.
http://productionadvice.co.uk/tidal-normalization-upgrade/
It doesn't solve it for CD's or Hi-Res downloads, but it's definitely a step in the right direction. If consumers start complaining that the music they purchase doesn't sound as good as what they can stream, hopefully producers will be quick to adjust... just as I imagine the HiRes guys will be quick to adjust when word leaks out that their CD's sound better than their FLAC's.
Enjoy!
Hi Archi, can you give me just a little help? I plan to shift my streaming system for mi RME ADI2PRO from mac mini to your Raspberry PI 3 B+ "touch". What kind of connection it's better to use in between? and what's the final "shopping list" of your touch system? Many thanks in advance and have a good day!
ReplyDeleteFrancesco
I am using an Rpi3 (not the B+) + official LCD display + Edimax USB WiFi dongle connected to a Teac UD-503
ReplyDeleteI can stream 384 kHz @ 24 bit pulling data from a NAS, wireless.
It is PERFECT, absolutely.
Same here only with internal wifi :)
Delete