• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Quality of Raspberry Pi4 USB For Streaming

Rate RPi Streaming Quality

  • 1. Poor (headless panther)

    Votes: 3 2.0%
  • 2. Not terrible (postman panther)

    Votes: 6 4.0%
  • 3. Fine (happy panther

    Votes: 24 16.1%
  • 4. Great (golfing panther)

    Votes: 116 77.9%

  • Total voters
    149
Sometime ago I had decided to dump the Pi4 and Moode Audio and replace it with something that was better. I tried all sorts. I ended up with a Pi5 starter kit that had a NVMe hat. I purchased a 500GB NVMe card to go with it. I must say it's superb. The speed of operation is so much better. I can download my music files on the NVMe and therefore have a backup of sorts. I tested Volumio and others and ending up going back to Moode Audio. Modde Audio has got everything just right. A very easy web based setup. It's openhome, and DLNA compatible. You can mount NAS drives or servers via FS or SMB. It can even act as a Wi-FI hotspot It can share the NVMe as a NAS drive as well. As usual with Pi's the OS is based on Debian Linux. So you can ssh in and take a good look at what it is doing if you are Linux literate. So simple and so cost effective. Just waiting for Qobuz connect at the moment if that is your thing. I only really use it to play music I've already researched on my PC (Linux) I can use Qobuz App for Linux as that supports connect for research. To date I've still to find a streamer ( no DAC ) that beats it. Yes I've tried some expensive ones but they all seam to be "Yet Another Android Based Streamer". I'm not really into the mobile phone size screens one you have got used to 24" displays. Just my thoughts.
 
Not sure you'll hear a difference changing DACs, I'd suggest considering getting a Roon subscription which will handle all of your offline files, and allow DSP and detailed metadata on your content.
 
The Rasperian OS does support UAC2 to the correct standard. If you have a DAC that doesn't support the protocol properly then the best thing to do is place it in the bin.
It supports the linux interpretation of the standard. MS, Apple and Sony have slightly different interpretations, as do some manufacturers. All have different tolerance for different aspects of noncompliance. For better or worse the interoperability testing often doesn't include linux (including Android). Linux isn't blameless here either - when Windows finally added UAC2 support it wouldn't work with linux gadget audio (UAC2 with linux as the DAC/ADC end). This turned out to be because MacOS, iOS and linux would still work if devices skipped a compulsory part of the standard, but Windows wouldn't work without it. Linux should have implemented this compulsory bit, but hadn't - it's now been fixed.

Don't bin it - that's a waste of money and unnecessary creation of e-waste. Sell it to someone who doesn't use linux or Andriod,
 
It supports the linux interpretation of the standard. MS, Apple and Sony have slightly different interpretations, as do some manufacturers. All have different tolerance for different aspects of noncompliance. For better or worse the interoperability testing often doesn't include linux (including Android). Linux isn't blameless here either - when Windows finally added UAC2 support it wouldn't work with linux gadget audio (UAC2 with linux as the DAC/ADC end). This turned out to be because MacOS, iOS and linux would still work if devices skipped a compulsory part of the standard, but Windows wouldn't work without it. Linux should have implemented this compulsory bit, but hadn't - it's now been fixed.

Don't bin it - that's a waste of money and unnecessary creation of e-waste. Sell it to someone who doesn't use linux or Andriod,
Wasn't this like 19 years ago? Did Windows ever catch up?
 
Wasn't this like 19 years ago? Did Windows ever catch up?
Somewhat more recent than that. The UAC2 driver finally arrived in April 2017 with the Windows 10 1703 update. The gadget audio compatibility problem was independently reported in a few places, and IIRC it took until 2022 to get all the wrinkles sorted and committed to upstream linux. And then a bit longer for the kernel or backports to make their way downstream again.
 
Sometime ago I had decided to dump the Pi4 and Moode Audio and replace it with something that was better. I tried all sorts. I ended up with a Pi5 starter kit that had a NVMe hat. I purchased a 500GB NVMe card to go with it. I must say it's superb. The speed of operation is so much better. I can download my music files on the NVMe and therefore have a backup of sorts. I tested Volumio and others and ending up going back to Moode Audio. Modde Audio has got everything just right. A very easy web based setup. It's openhome, and DLNA compatible. You can mount NAS drives or servers via FS or SMB. It can even act as a Wi-FI hotspot It can share the NVMe as a NAS drive as well. As usual with Pi's the OS is based on Debian Linux. So you can ssh in and take a good look at what it is doing if you are Linux literate. So simple and so cost effective. Just waiting for Qobuz connect at the moment if that is your thing. I only really use it to play music I've already researched on my PC (Linux) I can use Qobuz App for Linux as that supports connect for research. To date I've still to find a streamer ( no DAC ) that beats it. Yes I've tried some expensive ones but they all seam to be "Yet Another Android Based Streamer". I'm not really into the mobile phone size screens one you have got used to 24" displays. Just my thoughts.
Another plus for Moode is that it can act as a DLNA renderer or a LMS renderer. If you have an Android phone or tablet you can use Bubbleupnp to control Moode including playing Qobuz. I've been using Moode since v 2.x and love its flexibility.
 
I'll add to the praise of Moode Audio for the Raspberry Pi - it is getting better and better with each release. Props to @Tim Curtis for an excellent project! I'm running it on a RasPi 4, was previously using Volumio but the releases seemed to get more and more unstable so I finally couldn't take it any longer and switched to Moode.

Bubble UPNP mentioned above is great. I also recommend HiFi Cast - it basically lets you choose any source (local or network) and any destination (Moode, local renderer, etc,) - and it works a little better on my phone with scrobbling and that sort of thing. One missing feature on Moode is the lack of Last.fm and other scrobbling...

Another great thing about Moode? It now comes with PeppyMeter integrated - quite easy to use one of the HDMI outputs of the RasPi to display VU meters of different designs. I'm using a little 7 inch LCD panel I picked up from Amazon to show the meters. Pure aesthetics I know, but I love it!
 
Sometime ago I had decided to dump the Pi4 and Moode Audio and replace it with something that was better. I tried all sorts. I ended up with a Pi5 starter kit that had a NVMe hat. I purchased a 500GB NVMe card to go with it. I must say it's superb. The speed of operation is so much better. I can download my music files on the NVMe and therefore have a backup of sorts. I tested Volumio and others and ending up going back to Moode Audio. Modde Audio has got everything just right. A very easy web based setup. It's openhome, and DLNA compatible. You can mount NAS drives or servers via FS or SMB. It can even act as a Wi-FI hotspot It can share the NVMe as a NAS drive as well. As usual with Pi's the OS is based on Debian Linux. So you can ssh in and take a good look at what it is doing if you are Linux literate. So simple and so cost effective. Just waiting for Qobuz connect at the moment if that is your thing. I only really use it to play music I've already researched on my PC (Linux) I can use Qobuz App for Linux as that supports connect for research. To date I've still to find a streamer ( no DAC ) that beats it. Yes I've tried some expensive ones but they all seam to be "Yet Another Android Based Streamer". I'm not really into the mobile phone size screens one you have got used to 24" displays. Just my thoughts.
I love the options Moode provides. I setup a Pi 5 with an Argon case and 2TB NVME and it is nice having a standalone device with all my music and no network music source needed. I even setup an IR to control the basic functions with a standard remote.
 
I love the options Moode provides. I setup a Pi 5 with an Argon case and 2TB NVME and it is nice having a standalone device with all my music and no network music source needed. I even setup an IR to control the basic functions with a standard remote.
It's interesting reading that, and goes to show how we're all different. I would find it annoying as heck to have the music library disconnected from the network. Mine lives on a NAS, I edit the library over network from pc's, and play over network with LMS running on a Pi4. Not only is doing it all over the network a feature (to me), but so is not having to have storage on the Pi.

I'm not trying to say you're wrong, or even that you consider doing anything different. Perhaps I'm just observing that there are a huge number of completely valid use cases. It could be viewed as a pain for somebody developing products in this space, or an opportunity.
 
Last edited:
There are quirks even for streaming audio on some hardware. See https://github.com/torvalds/linux/blob/master/sound/usb/quirks-table.h - things like advertising sample rates and/or bit depths that don't actually work.
Advertising supported samplerates and/or bitdepths is a DEVICE responsibility, not a HOST one to comply with.
If we are strict to what the device tells us it can do, then we are safe. Provided it actually does what it says.
Apart from that, every UAC-compliant device (better UAC2 as it is asynchronous) is capable of 44.1/16 (aka CD-quality), and that is enough for the vast majority of ears out there...

To paraphrase a common meme nowadays: "Prove me wrong".
 
It's interesting reading that, and goes to show how we're all different. I would find it annoying as heck to have the music library disconnected from the network. Mine lives on a NAS, I edit the library over network from pc's, and play over network with LMS running on a Pi4. Not only is doing it all over the network a feature (to me), but so is not having to have storage on the Pi.

I'm not trying to say you're wrong, or even that you consider doing anything different. Perhaps I'm just observing that there are a huge number of completely valid use cases. It could be viewed as a pain for somebody developing products in this space, or an opportunity.
I love your setup and I do have a server side music setup as well on my Mac that I use across my house. The main reason I setup a Pi this way is for flexibility when I travel for work and it provides an additional backup for my music library.
 
I love your setup and I do have a server side music setup as well on my Mac that I use across my house. The main reason I setup a Pi this way is for flexibility when I travel for work and it provides an additional backup for my music library.
Oh! I appreciate that scenario. I regularly sync my library to a thumbdrive so that I have it in the car. That library is always lacking my latest acquisitions because I dislike that routine. “Regularly” ends up being only 3 or 4 times a year.
 
Advertising supported samplerates and/or bitdepths is a DEVICE responsibility, not a HOST one to comply with.
Theory and practice differ widely. Many manufacturers did not (some still do not) care about UAC1/2 compliance because they supplied their own custom drivers for Win/OSX. If users want to use such devices on linux/android, the driver has to implement the necessary quirks.
If we are strict to what the device tells us it can do, then we are safe. Provided it actually does what it says.
That "provided" is the core of the argument - read the comments in the quirks code - many many devices actually do not do what their usb config or UAC1/2 standard says. Plus the standard defines in detail only a subset of needed features, some features are defined vaguely, some not at all (DSD format - part of UAC3 only, standardized SPDIF preamble configuration, etc.)
Apart from that, every UAC-compliant device is capable of 44.1/16 (aka CD-quality)

Where in the UAC1/2 specs is this required? Please quote. There are UAC2-compliant devices (especially the newer ones) which support only 24 or even only 32 bits. Also many devices with more than 2 channels (and no 2 channels-only alternate setting)


(better UAC2 as it is asynchronous)
Asynchronous mode is specified for both UAC1 and UAC2 devices. An adaptive device can be perfectly UAC2-compliant. Just like there are (older) UAC1 async devices.
 
Theory and practice differ widely. Many manufacturers did not (some still do not) care about UAC1/2 compliance because they supplied their own custom drivers for Win/OSX. If users want to use such devices on linux/android, the driver has to implement the necessary quirks.
That's it right there. Windows and MacOS don't need this stupid quirks table (or the associated wait for the quirks patches to make it to your distro) because the device companies provide their own drivers that deal with the quirks. The device companies don't do Linux drivers, so the Linux kernel devs have to work it out.

Devices frequently don't work the way the spec says, for all kinds of reasons. Often it's just a bug that hardware/firmware devs didn't bother to fix because it's easier to work around in the driver. Sometimes it's engineers being engineers, knowing they can do better by breaking out of the constraints of the spec. The reasons don't really matter, though: USB spec incompatibilies that can be hidden by a device driver are the proverbial tree that falls in the forest that no one is around to hear.

To think everything follows the spec is... well that's a world where laws are never broken, products never recalled, and no birth defects.
 
Theory and practice differ widely.
I fail to get your point, actually.
Are you just saying that there are some (many???) UAC1/2 (or even 3) devices that fail to play unless you ahve a proper (manufacturer's) driver?
If you refer to specific settings - like volume control, for instance - I may agree, but playback, no. I haven't yet encountered a device that does not simply play in Linux.
In the past 14 years or so, at least.
An example, so that I can eventually try?

Regards, Al.
 
I fail to get your point, actually.
Are you just saying that there are some (many???) UAC1/2 (or even 3) devices that fail to play unless you ahve a proper (manufacturer's) driver?
If you refer to specific settings - like volume control, for instance - I may agree, but playback, no. I haven't yet encountered a device that does not simply play in Linux.
In the past 14 years or so, at least.
An example, so that I can eventually try?
A trivial search which you can do on your own, e.g.:

https://github.com/torvalds/linux/b...33d2bee170af5e71/sound/usb/quirks.c#L902-L904 -> https://github.com/torvalds/linux/commit/cb99864d40e46dea9c2aa3eaa97517b776f91024

https://github.com/torvalds/linux/b...33d2bee170af5e71/sound/usb/quirks.c#L981-L985 -> https://github.com/torvalds/linux/commit/16bafa792c860e50768b2527ded364137c6ed21e
 
No need to apologize. Linux kernel source code is a unique source of detailed information on computer hardware.
 
Back
Top Bottom