Asynchronous USB at high rates on Raspberry Pi

Audio Gear Talk Raspberry Pi
1

There seems to be a generic challenge with Roon Bridge on (Raspberry Pi) Linux systems. Roon uses ALSA, and ALSA seems to have problems with asynchronous high rate DACs (edit: see below).

I have tried Rasbian on the PI B and the B+, and Ubuntu on the Odroid C2. I see many posts in forums about dropouts or even just noise at sampling rates above 48 kHz on USB. Sometimes this can be hardware (especially on the Pi B, with its shared bus), but there is a fundamental software issue which seems to be that the ALSA subsystem is not designed for 1) higher than 48 kHz on USB, and 2) asynchronous USB, which would require a different driver approach. At least this is what I gather from experience and browsing many forums.

In particular, Roon Bridge loads and works fine on Pi B, B+, and Odroid C2 (armv8 version). All three have the same observable problem of pops and garbling at 176 and 192 rates. I have checked and eliminated any network issues, and in particular, on Ubuntu on the C2 I have monitored CPU and network usage while streaming-- both low. Roon reports no problems.

What are the solutions? Custom drivers would work of course, and may be why custom Roon Bridges and appliances work fine, but what is available off the shelf and open source? Does Dietpi work for this situation? I see it is going to push higher on the HDMI interface, but how about USB? Anything else? I see lots of random tweaks of configs, but they seem to work by accident if at all.

2

You need to use OSā€™s on the endpoints that are specifically being developed for audio use, so in our case Ropieee or DietPi, both of which are being patched to deal with big PCM and even native DSD. I have a C2 and I note itā€™s kernel was not as new as the same OS on the RaspberryPi. It still handled up to 192 with ease so I would suggest scoping the more audio oriented operating systems.

3

Iā€™m using dsd256 and dsd512 happily on ropieee with usb and lan on RPi 3b

4

Hi @John_Kroeker,

Thereā€™s nothing ā€˜fundamentallyā€™ wrong with USB Audio (and Alsa) on Linux. The stack can handle very high rates (704K), so donā€™t worry about that. What you can run into is the simple fact that itā€™s a lot of data, simple as that. When doing this on a device that has limits (pi usb design for example), then you can run into trouble.

Also keep in mind that on Linux you donā€™t need specific drivers for a specific USB DAC. I think thatā€™s a huge advantage compared to Windows. The only real software challenge that we have is that the kernel needs to be patched for native DSD support. This is not something you can ā€˜blameā€™ the Linux kernel for: itā€™s just that the UAC standard did not take DSD format into account.

If you really want something ā€˜betterā€™ then USB then you could think of I2S. That has it challenges too (itā€™s an internal standard, not meant to be used in consumer land), but more and more devices are capable of handling I2S streams directly.

Keep in mind though that the limitations for the hardware (like the pi) also are in effect for I2S though.

Thanks,

2 Likes
5

Iā€™ve never had an issue myself with 384 or DSD256 on endpoints running Arch, Debian or Ubuntu.

Anyway, that doesnā€™t help anything! You donā€™t mention what specific DAC(s) you are using, that might shake something loose from the many knowledgeable folks here.

I use a Cubox and a minimal Arch Linux install so my only thought is a general one. I run the most conservative CPU governor available on my endpoints. Often the default is max performance, so it might be interesting to see what happens when the endpoint is running at whatever its lowest speed is, something like 600 mhz in my case. (And itā€™s plenty to pass a DSD256 stream on to my DAC)

1 Like
6

Thanks for all the info. I am using a Channel Islands Audio Transient Mark II DAC, which interfaces with the USB with an XMOS chip. It works perfectly on both Windows and Mac. Still trying to sort out the haze of posts on many forums! Some say it is which kernel, some say which platform, some say which DAC. All of which may be true some of the time or all of the time, hard to know a priori. I want this to work, because Windows is now effectively unstable, and I donā€™t like connecting it directly to sensitive audio equipment.

I will try both the Ropieee solution and the dietPi path and repost when I have some results. Both the PI B+ and the Odroid C2 should have plenty of bandwidth in general. I would prefer a solution which allows Spotify to coexist on the bridge-- and DietPi may do that. Or I may get addicted to Tidal and be fine.

I agree with Spockfish that Linux ought to work fine, but I do see lots of noise around the ALSA, at least in the Raspberry world. I may have hit an unlucky patch on my three trial boxes. To Lorinā€™s points, nice to see Ubuntu can work, and so it ought to work on the C2, so maybe, re Henry, I can try to update that to current. I love being able to remote desktop into it to check it out easily on a big screen.

Thanks again, will get back.

7

As promised, I am back with some tests. Still stumped! I have loaded DietPi on the Raspberry B+. I like DietPi; the directions are correct and easy to follow and RoonBridge installs fine. The sound is better-- however, I am still getting little pops and ticks and a hard-to-define distortion, I suppose from drop outs.

I uninstalled all the other software from DietPi and checked with HTOP, few processes running, mostly Roon stuff, but no change. I tried another DAC, the Schiit Modi 2, purchased for this purpose, no change. Iā€™ve tried lots of different buffer settings in Roon, no change. Well this moves the pops around a bit, sometime more frequent, sometimes less. I installed DietPi on the Odroid C2: results were worse.

Both DACs work beautifully on the USB 3.0 port on my Windows 10 workstation. That seems to eliminate the server side for problems. Ethernet? I have tried two different gigE ports on the workstation. There is one hop through a brand new Netgear gigE switch. I removed all the other devices from the network, no change. Power noise? I can power my CIAudio DAC from a regulated power supply, so I did, no change.

I canā€™t completely eliminate the ethernet link, but I canā€™t think of what else to try there. The effect I hear is very definite, but not large. I wouldnā€™t hear it if I didnā€™t A/B to the good source and listen very closely to quiet selections. To be specific, as reported by Roon, the source is FLAC 192kHz, 24 bits, 2 channels.

I am surprised at the Odroid, it is said to be a heavy hitter. It is possible that for this purpose, moving data from the ethernet to USB, it is not. The problem seems to be a bandwidth issue, and there is no reason to suspect the OS (eating my hat here), although I canā€™t eliminate it either. Well, I am stumped. On to the Tinker Board? Cubox? I donā€™t really want an entire shelf full of these little things, cute as they are.

8

@John_Kroeker you keep mentioning the pi as b or b+ but is it a pi 3b or 3b+ as much less than that that might struggle with higher bit rates

Likewise you havenā€™t indicated is this LAN connected or wifi?

9

I have a Pi 3B+, and yes it is LAN connected.

10

I just tried ropieee on the Raspberry Pi 3B+. Ropieee downloads and configures like a charm. The dropouts are worse than before. So on the 3B+, whether Raspbian, DietPi, or ropieee, I have the same difficulty with USB at 192k/24 bits. Sure seems like a hardware limitation.

11

Hi, how are you powering your DAC?

12

I use a Ropieee RPi 3b and I can stream DSD512 with no issues at all using LAN and DSD256 with wifi - not my preferred rate but I tested it with wifi and that was OK too for many hours but the wifi and RPi within a couple of meters of eachother.

13

The Schiit DAC is USB powered from the RPi, the CIAudio can either be powered from the USB, or from a standalone, regulated PS.

I have tried all the possible configurations, no change. Power noise could explain the ticks and pops, but I donā€™t think it can explain the stuttering I get in extreme cases.

Just ran ropieee on the RPI 3B+ again to check. A 44.1kHz16bit source sounded fine. A 176.4k 24bit source had pops, and a 192k 24bit source had stuttering.

14

Hi,
I donā€™t know how DSD works at the data transmission level, but I ran some numbers for 2 channels at different rates, just for interest:

                 mbits/sec   mbytes/sec
dsd512           5.6448	
192kHz 24         9.22        1.15
176.4kHz 24      8.47         1.06
USB 2.0 max      480

There is control overhead of course, but USB ā€œshouldnā€™tā€ be a constraint.
Cheers

15

Iā€™ve had similar issues in the past, particularly before I switched to DietPi and later Ropieee. Iā€™m using a RPi 3. It mostly drives an Oppo 105D, and is solid up to 352.8/24 or DSD128 via DoP. Iā€™ve heard some stuttering with other DACs I own, so I suspect that how much buffering the DAC does may matter. Th real problem with all of the RPiā€™s is that the USB and Ethernet share a connection to the CPU/RAM, and thatā€™s why you get the problems ā€” but better software helps a lot, at least with the right DAC.

Good luck!

16

Yes, thanks. I have now tried the Tinker Board, and problem solved. Roon Bridge performs like a champ on both my DACS, and on either DietPi or TinkerOS. I have tested up to 176kHz/24bits,and the sound is stunning.
I did finally give up on Spotify (raspotify),and went with TIdal, so I only need the Roon Bridge to work. Not having separate clients and apps on remote devices will make the system much more user-friendly.

I heard that the Tinker Board is fine with up to 384 kHz/32 bits (PCM) on USB. That is still way below the nameplate rating of USB, so it does appear that some hardware design choices limit the Raspberries and the Odroid C2. Thanks to all for the help.