DACs' compatibility with Linux

[KSTR]

ADI-2 Pro, speaking of which... I just finished setting up a new system with an Ubuntu 18.04 LTS. While the RME worked right out of the box there was the issue that everything was resampled to 48kHz.
It turned out one has to disable pulseaudio for that device so that ALSA has full and exclusive control: https://lukas.zapletalovi.com/2020/07/force-pulseaudio-to-ignore-a-card.html
Only after that, bit perfect playback is established (checked with RME's bit-test files). In the DeadBeeF music player which is what I used for checking, one has to additionally untick the resample option in the alsa output plugin's config.

 

[somebodyelse]

it will work IF it doesn't rely on (OS) software for function. once it does it needs a special driver.

If only that were universally true. It should work, but occasionally it won't. See for example @q3cpma's example with the MOTU M2 above, or the linuxmusicians thread about the problems with the Ultralite AVB (and others in their AVB series) in class compliant mode. The expectation with the AVB models was that they'd be fine because the audio part was class compliant, and all the controls, which usually cause the problems, were done via a web interface not the driver. Or in the other direction the linux gadget audio driver (make your pi zero look like a DAC to the computer you plug it into) which works fine with linux computers, Macs, iPhones but not Windows 10. The gadget driver is meant to provide a class compliant interface, but it's missing a part that the spec says isn't optional, but nobody worried because for years it worked with all the computers anyone tried it with. Windows 10 finally added a built in driver for class compliant devices, and it insists on this missing bit being present.

 

[somebodyelse]

Have you tried the recently released Moode 7.0? I've never experienced any audio glitches on either Moode or Volumio on an RPI 4.

The key here is the RPI 4 - it has proper USB host ports instead of using the USB-OTG interface in host mode, and doesn't appear to suffer from this bug via those ports. The USB-C port that's usually just used for power is actually an OTG port and can be switched to host mode, but that's not exactly a normal use.

 

[danadam]

ADI-2 Pro, speaking of which... I just finished setting up a new system with an Ubuntu 18.04 LTS. While the RME worked right out of the box there was the issue that everything was resampled to 48kHz.
It turned out one has to disable pulseaudio for that device so that ALSA has full and exclusive control: https://lukas.zapletalovi.com/2020/07/force-pulseaudio-to-ignore-a-card.html
Only after that, bit perfect playback is established (checked with RME's bit-test files).

Or, from pulse-daemon.conf manpage:

avoid-resampling= If set, try to configure the device to avoid resampling. This only works
on devices which support reconfiguring their rate, and when no other streams are already
playing or capturing audio. The device will also not be configured to a rate less than the
default and alternate sample rates.

 

[Mark Dirac]

there’s usually an Allo USBridge person lurking here
https://audiophilestyle.com/forums/topic/57258-allo-usbridge-signature/#comments

EDIT: oops, saw you already contacted Allo

Yes, thanks. That forum is controlled by Allo. Allo's support is quirky - and not in a good way. They sell with virtually no documentation - either on paper or on their website. There are even a few things which are essential to know for their products - they will not work otherwise - but don't even warn/document these. Instead, they pay for this corner of Audiophile Style's website. It is called a "club". When people post a query, Allo usually answer with an invitation to post a PM. Allo respond privately within about a day - only one query at a time per day - and so the community in general never gets a full picture of the queries and solutions regarding a product's quirks. There is no FAQ anywhere. It is there that I learnt - from Allo - that there are issues with some popular DACs on linux. But nothing more illuminating.

You guys have been much more helpful than that forum and I have almost found a workaround to my issue. (Will post when resolved.)

 

[abdo123]

Yes, thanks. That forum is controlled by Allo. Allo's support is quirky - and not in a good way. They sell with virtually no documentation - either on paper or on their website. There are even a few things which are essential to know for their products - they will not work otherwise - but don't even warn/document these. Instead, they pay for this corner of Audiophile Style's website. It is called a "club". When people post a query, Allo usually answer with an invitation to post a PM. Allo respond privately within about a day - only one query at a time per day - and so the community in general never gets a full picture of the queries and solutions regarding a product's quirks. There is no FAQ anywhere. It is there that I learnt - from Allo - that there are issues with some popular DACs on linux. But nothing more illuminating.

You guys have been much more helpful than that forum and I have almost found a workaround to my issue. (Will post when resolved.)

The only issue you need to resolve is the fact that you’re using inherently defective snake oil.

Save yourself the trouble and purchase a Raspberry pi 4. If not for a proper USB bus then for Bluetooth and Wifi.

Using both LAN and USB on a raspberry pi 3 is a recipe for audio disaster and that could be your problem.

 

[Mark Dirac]

Save yourself the trouble and purchase a Raspberry pi 4.

Yes, thanks. I intend to investigate this further. (Different topic.)

 

[somebodyelse]

Using both LAN and USB on a raspberry pi 3 is a recipe for audio disaster and that could be your problem.

That's at best incomplete and at worst spreading the usual disinformation. The LAN is at best a minor part of the recipe, making the problem a little more likely to occur. Sample rate is more of an influence in that respect - changing from 44.1k to 96k has more effect than going from WiFi to LAN on the Pi 3. The biggest influence, and perhaps a necessary part of the recipe, is the choice of software, and in some cases the exact configuration of that software. I have tried and failed to reproduce this problem when using piCorePlayer, but can reliably reproduce it with Volumio and Raspbian when using BruteFIR - unless BruteFIR is pinned to a single cpu core, in which case the problem disappeared.

I'll agree that the Pi 4 is a good way to avoid problems with the Pi 3 if you want to use one of the problem software combinations.

 

[julian_hughes]

My desktops and servers have been running (Debian) Linux since 2007. I also have a few embedded devices (orangepi & raspberrypi) running armbian, and I used to run routers on openwrt (no need to anymore as my ISP actually supplies decent kit & updates it...it runs Linux). I've been running USB DACs on Linux for about 5 years. I've used some synchronous and some asynchronous DACs & devices. Essentially everything worked out of the box as the Linux kernel includes all the necessary drivers for any USB standards compliant device. You just set up alsa so the default device is your hardware DAC & you have bitperfect audio. It was so easy! And recent versions of pulseaudio allow you to choose to avoid resampling so you can even run a desktop OS with a software mixer and *still* expect unmodified audio.

This is still the case if your audio source files are on disk. But something changed so that now if you stream audio and your audio is passed off to a USB DAC then you get crackles and pops. It is horrible. And it's the same on x86 hardware as on ARM. I have an OrangePi One and an OrangePi PC2 running as streamers. My raspberrypi is kind of retired but I try stuff out with it. It used to be so easy, then I upgraded from Debian Stretch and it all turned to crap. Same with my x86 server. My solution was to revert the orangepi devices to Debian Stretch with 4.19 kernels and the CPU frequency scaling set to a fixed frequency. These are devices dedicated to the one task of passing data to a DAC so it's acceptable to tweak them specifically to this. But it didn't used to be necessary. My x86 server performs multiple tasks and really needs the frequency scaling to work so I can no longer use it for audio.

I'll reiterate: everything is fine with playing back files, the problems arise when the device is required to handle a stream i.e. it's working as a UPnP renderer. It's not specific to raspberrypi but appears to be a more general problem. If this same problem exists outside the Debian & Debian derived environment I don't know but will be checking soon (by installing arch linux on a spare SSD and testing it).

Anyway, my advice to anyone wanting to run a raspberrypi or orangepi or even an x86 PC as an audio streamer is to go all the way back to Debian Stretch, disable the cpu frequency scaling and it will work fine. Luckily rendering audio requires almost no CPU power so you can set the CPU to a very low frequency, save power, keep it cool easily and everything is fine.

 

[KSTR]

Or, from pulse-daemon.conf manpage:

Ah, thanks for that. Works even better than disabling the device for pulseaudio alltogether, rather it remains available for the standard applications (streaming etc) but won't clutter an audio player's output.

 

[somebodyelse]

@julian_hughes I've not encountered that with Ubuntu (so debian-based) or Gentoo on PC hardware, and on the Pi the problems are limited as I described earlier. I haven't tried a USB DAC on the PinePhone, and don't have an OrangePi. I use LMS rather than UPnP though.

 

[Mark Dirac]

My desktops and servers have been running (Debian) Linux since 2007... Anyway, my advice to anyone wanting to run a raspberrypi or orangepi or even an x86 PC as an audio streamer is...

Thanks Julian for your comprehensive post. I imagine that the difference between your experience and somebodyelse's experience could well be explained by the two of you using different DACs?

 

[julian_hughes]

Thanks Julian for your comprehensive post. I imagine that the difference between your experience and somebodyelse's experience could well be explained by the two of you using different DACs?

It could be the difference between DACs using USB 1.1 and 2, or devices being or not being fully standards compliant, or it could be issues around the kernel schedulers, frequency scaling and powersaving. Or something else!

 

[Mark Dirac]

Have you tried the recently released Moode 7.0?

Thanks. I checked the release notes and there's nothing in there to suggest any changes which might affect this. But I will try it in due course. (Too many things to try to be able to listen to music!)

I've never experienced any audio glitches on either Moode or Volumio on an RPI 4. Volumio is dog slow and buggy but once it actually deigns to play something it is glitch free even running Brutefir. Dac is Topping E30 via USB.

Thanks. That suggests that there's no general company-wide Topping issue then.

My understanding is that the Qobuz MPD plugin is deprecated and unsupported on Moode (and elsewhere?) due to Qobuz changing (and actively obfuscating) the API ...

Yes. The "problem" is with the moOde plugin "upmpdcli " (UPnP music player daemon client). It seems the developers were given the run-around by Qobuz and eventually gave up. In moOde 7 the develpers have removed the redundant code enabling log in to Qobuz. (I say "problem" because the problem seems to lie not with moOde or upmpdcli, but with Qobuz.)

on Moode (and elsewhere?)

Fortunately I use the work-around whereby the android app called bubbleUPnP authenticates my Qobuz credentials and facilitates upmpdcli and moOde to draw and play my Qobuz stream. I do not understand how this works, but am mightily impressed. I am warned that Qobuz may block this at some point. Again, I do not understand why Qobuz are not prepared to assist these guys, but instead seem to obstruct them.

 

[danadam]

Ah, thanks for that. Works even better than disabling the device for pulseaudio alltogether, rather it remains available for the standard applications (streaming etc) but won't clutter an audio player's output.

No problem.

If you don't mind, could you check the issue described in https://www.audiosciencereview.com/...audio-and-strange-sampling-rate-change.17652/ ? (The steps described there use "alternate-sample-rate" but it is the same thing with "avoid-resampling".)

 

[bluefuzz]

Again, I do not understand why Qobuz are not prepared to assist these guys, but instead seem to obstruct them

I think it's the same with all commercial streaming services whether music or movies – as soon as something smells of open-source the rights holders get antsy and put pressure on the service to limit access to such devices/software because hAcKeRz ... ;-)

 

[julian_hughes]

@julian_hughes I've not encountered that with Ubuntu (so debian-based) or Gentoo on PC hardware, and on the Pi the problems are limited as I described earlier. I haven't tried a USB DAC on the PinePhone, and don't have an OrangePi. I use LMS rather than UPnP though.

I went back to some of my devices and started over. On my orangepi (arm64) devices I find I can run Ubuntu Focal (as it's LTS) and have my DACs work fine, with cpu frequency scaling and default governor, other tasks being performed, system updating in background etc. Everything normal & glitch free bit perfect playback. On amd64 (actually Intel Core i5 Sandy Bridge) running Debian Testing with a 5.9 kernel it's also working perfectly. On Debian Stable on amd64 (one server running AMD Turion and another running Intel Atom) it's still a problem. I really can't tell if the problem is with the kernel scheduler, the upnp libs or whatever, but it seems that the issues existed in Debian Stretch and Buster but not in older or more recent versions i.e. Wheezy or Bullseye respectively. I do recall trying Ubuntu Xenial & Bionic on my arm64 devices and having the same issues. I tried Archlinux this week but the 3rd party/AUR packages are in a sorry state and it didn't prove possible to get a working version of gmediarender and the required upnp libs. I don't have the will power to try gentoo or funtoo again , especially not on embedded devices.

 

[somebodyelse]

They only audio issues I had in Xenial and Bionic were related to me doing non-default things with it.
Edit: we're unfortunately into the area where there are too many combinations of hardware, software and versions to be sure all the combinations work, much like Windows. You've dug deeper with more hardware than most, and know enough to at least have an idea where to dig deeper if you have the motivation.

I don't have the will power to try gentoo or funtoo again , especially not on embedded devices.

Once you stray far enough from the binary disros' packaging decisions it becomes less frustrating than trying to bend the disro to your will Also less frustrating than dependency versioning used to be in OpenEmbedded...

 

[Nicolaas]

Probably this is a performance issue of your rpi 3b.
I have used 3 different DACs on my Linux mint systems, latest the D90.
On my 13 years old Sony Vaio laptop I heard regular glitches especially while listening to 24b-96k flac files. From a website I learned that resources are shared between Ethernet and USB networks. So when listening to my flac files including 24b 96k I always disabled networking. This solved the problem with glitches on my very old laptop especially with high res files. In a later stage I replaced the hard disk in my Vaio with an SSD. Then my old Vaio was very suited for playing high res material. However a few months later the graphical card died. Then I bought a cheap Intel NUC with pentium quad core processors and swapped my Vaio ssd to the Intel NUC. Current OS is Linux Mint 20 Xfce. Player Audacious/ALSA.
Long story short: I now have a great high res player without any glitches! And Linux recognises my Musical fidelity, Topping D90 and USB audio player pro dacs without any problems.
BTW I also bought a medium priced Audioquest USB cable but of course this did not solve my hardware resource problem (glitches)...

 

[zenki]

Used hidizs s9 on linux with audacious. Perfect.
Better than windows/android.