The Raspberry Pi is being used as a platform for Roon Bridge or an HQP NAA but suffers from the design decision to have Ethernet and USB on a single bus meaning the bandwidth limit is shared between those inputs/outputs, rather than separate limits applying to each (as with CuBox-i, BeagleBone Black or WandBoard).
This creates pops and clicks when using Hi Res Ethernet in, USB out.
The HiFiberry Digi+ provides optical and coax S/PDIF out, but USB can be preferred so that RAAT lets the DAC own the clock.
So although it seems ridiculous on a device with 4 USB ports, there may well be interest for a HAT, which uses an l2s output, containing a well implemented further USB port. They may already exist, but I haven’t seen one.
Flagging this for @Michael_Kelly of Pi 2 Design who asked about design requests.
I’m running a USB DAC on a Pi 2 without issue. I can stream 384kHz/24bit PCM and DSD128 without any clicks or dropouts. I use a cabled Ethernet connection directly attached to the 1000Mb/s switch that the NAS uses.
Perhaps the issues are related to WiFi or network issues rather than the architecture of the Pi?
It’s quite possible that in some cases network issues are the problem.
I found intermittent pops and clicks using a Pi 2 and DSD 128 but PCM 192 was fine. Others reported those artifacts becoming much more prevalent at DSD 256.
The Pi’s bus drivers have improved over time (mainly timing-wise), making this less of an issue than it was. Still, the 480Mbps shared bus issue remains. I find that I’m fine up to 192 – any higher things get critical (wired on a 1Gbit switch): it mostly works.
I like the idea of a stable, non-saturated USB HAT. But then again: why not just use a Cubox/BB/WB? Horses for courses, I guess. The Pi is fun, but hardly the only game in town.
Yeah – I think WiFi on the Pi is rubbish. Even at close proximity to the AP (Airport Extreme) and no case on the Pi, bandwidth varies wildly. Redbook is pretty stable, but higher bitrates were pretty much hit or miss for me.
Then again, IMHO wireless is a recipe for disaster when steady bitrates are required. It usually works, but it always tends to break down in that one free hour of listening time in a busy week… (I learned the hard way in my Squeezebox days – and even with Sonos. Sooloos forced me to finally get wired up in all audio-related spaces, and it has paid off big time ever since).
We’ve done a few audio hats for the Pi and I find this thread very interesting. We also have an SSD hat with WiFi that supports an eternal antenna. One question: would having local storage, say 32-64GB help these network issues? We’re thinking of maybe combining the SSD and WiFi functions with audio DAC onto one add on board specifically for this audio endpoint use case.
For Roon, local storage is not important in an endpoint like the Pi – all audio is streamed over the network from Roonserver to Roon Bridge through RAAT (Roon Advanced Audio Transport).
Havent tried the Pi but dont like the idea of USB and Ethernet on the same bus, so tried Beaglebone and Beaglebone Black. Both have even uglier USB issues. DMA is broken, so only PIO and massive amount of interrupts. Hickups at 96/24.
Just ordered a ODROID C1 which has the same ARMv7 platform and will give it a try for endpoint.
Minnowboard (x86_64) could also be interesting but is not (yet) available and much more expensive.
Dont know… have a WaveIO XMOS USB-to-I2S board, async USB and many different kernels running MPD. Never tried Roon on it, but dont think Roon can work around a broken USB implementation TI even acknoledged it in some forum… So Im done with Beaglebone. Would have been a nice board.
Check cat /proc/interrupts and you probably see lot of interrupts for USB.
Been using an ODROiD C2 for a long time now without any issues, regardless of what’s streamed. If you don’t like to tinker get the C1, otherwise you have to tinker until such time Roon release an ARMv8 build of Roon Bridge, which is planned, but no indication of timing.
Update: While working with XMOS DAC, always crashed with a DragonFly Red. Looking at the ODRoid forums, seems there are many usb/alsa related problems. Im back to an Intel NUC DE3815TYBE and everything runs fine again. For now Im done with ARM boards…
Implementing I2S over HDMI (via LVDS) is pretty straight forward. Not sure about the USB though. The limitations with the pi regarding USB are well known. Adding a USB port via a USB hub would do nothing for the performance.
I have been giving some thought to modifying our 502DAC and adding I2S where we have the status LED’s. I will post more about this on the SBAF forum soon.
TI even acknoledged it in some forum… So Im done with Beaglebone. Would have been a nice board.