RoPieee crashing my DAC

If you search the forum you will see a trend forming. It’s only started since the update that introduced upsampling of low Res content.

I’ve posted a thread here
https://community.roonlabs.com/t/dac-issues-with-xmos-usb-chipset-and-roon-on-linux/52911/2

@CrystalGipsy on my rpi 3b (not the +) I run dad 512 native to my Usb connected dac and Ethernet with no issues…I will try this also on the 3b+ at some stage when I get a min…if this is failing then I’m not sure what the benefit or advantage is of the + models at all for audio streaming.

1 Like

@spockfish: Now I’m not sure it’s the DAC – it may be the RoPieee drivers.

I was originally running RoonBridge on a Mac Mini (old, 2010, core 2 duo) which in turn was running Xubuntu 16.04, with the Liberty DAC plugged into the Mac’s USB port. And I didn’t remember having these issues. So I unplugged the RoPieee box and plugged the Mac Mini back in. Sure enough, I can now play the “crash DAC” playlist without an issue, over and over again.

I can gather logs from the Mac if that would be helpful.

So, both running Linux and RoonBridge. The Mac is an Intel chipset, of course, while the Pi is ARM. Surely different USB drivers.

It’s not.the DAC it’s Roon.

OK, but then I’m asking, why does it happen with Linux endpoint 1 (the Pi with RoPieee), but not Linux endpoint 2 (the Mac Mini with Ubuntu)? Same DAC, same USB cable, same Ethernet cable. Both running Roon Bridge. Could be a race condition of some sort, I suppose.

Reading this page made me more skeptical about the ability of the Pi hardware/drivers to handle things without data loss:

Split transactions that span multiple packets are disrupted
Typical symptoms are static in the background of audio recordings or sound output.
Audio playback or record requires a multi-step split transcation, which must be precisely scheduled and completed in the right order and at the right time. If the USB driver misses sending a split transaction packet, then the data is usually lost. The greater the bitrate or number of audio channels used, the greater the corruption of the signal. Adding to the interrupt loading of the Pi through use of the SD card or ethernet will increase the static.

1 Like

The pi’s not great for USB period that’s why you got dropouts when you upsampled to 384/24. The new pi3b+ is the worst due to the gige ethernet adaptor that shares the same bus. Apparently there is away to nobble the driver to make the network run at 100mb and this improves it. Personally I never used it as it was unreliable.

I guess Ubuntu and maybe the Mac hardware is better at dealing with your dac than Ropieee is. Are you running it nativley on it or docker/VM as that might account for it?

But the symptoms you where having are identical to the known issue.

According to the changelog, the estimable Meneer ten Berge has already incorporated that patch.

Natively. This is why I suspect the device driver. The Mac has different hardware and different device drivers. Of course, the hardware may be so bad on the Pi that no amount of device driver improvement could save it.

It’s got 5GHz wireless that’s the only benefit. Switching to wireless I could at least get 192/24 without it being a complete click fest. With the ethernet it was just awful. I think it’s also probably combined with the Roon and the known Xmos chipset issue. But the pi and usb is heavily DAC dependant, there equally as many users with problems as there are without. Down to poor Linux driver support likely.

1 Like

Excellent idea there!

I enabled the WiFi and unplugged the Ethernet connector. Now it switches flawlessly between MP3, MQA, and regular CD quality. Back to the Pi.

Thanks for the tip!

Hope it lasts.

https://en.wikipedia.org/wiki/Learned_optimism :slight_smile:

2 Likes