Raspberry Pi USB - some theory?

[rwanou]

Hi All,

I'm soon to invest in an extra HiFi setup for my Corona Home Office, so I'm loosing some time on the forums trying to figure what my next DAC will be. I have a bunch of old Raspberry Pis rotting in the basement, and I thought I could re-use one of them to create an audiophile DAC. I already have 2 RPI with a Justboom AMP hat to power some integrated speakers in my home (1 stereo in the playroom, 1 divided into 2 mono entities for the 2 bathrooms). There is an extra Raspberry Pi zero with the Justboom DAC hat connected to my living room amp. Everything runs on PiCorePlayer, I'm quite happy with the result.

Now, I've been reading on this forum and elsewhere that the RPI 3 USB port is noisy. Apparently this is backed up with tangible measurements. But could someone explain the theory behind this noise? My limited knowledge has me thinking that a signal over USB is purely digital. Meaning that the quality of the transmission matters little as long as the message passes to its destination. The audio file (FLAC, MP3...) consists of bits of data that needs to be passed in whole to the DAC. In case noise interferes with the message, polluted packets should be invalidated and sent again. The result being that the DAC would receive basically the entirety of the source file, and then it should be fully capable of converting it to Analog signal, with its given quality (precision of the clock, quality of the chip etc.). I'm pretty sure the bandwidth of USB is more than enough to absorb any overhead of sending the data twice if signal is really poor.
I have the same question regarding high end expensive audiophile ethernet cables (although I don't want to open the Pandora box). Is it really necessary to invest in a 1000$/m ethernet cable when any cat6 cable can handle 1Gb/s and that TCP/IP protocol guarantees the integrity of the data?

I'd love to read some decent explanation on this matter.

 

[Sukie]

There are issues with usb audio on RPi3 and earlier, but this isn't to do with a noisy port and only relates to certain software.

There's some good info on here. I'll try and find references when I've got time. Of all the members, @somebodyelse has helped me the most on this subject.

On cables, a quick "no" is more than sufficient!

 

[somebodyelse]

We probably ought to have an FAQ section for this.

There is a genuine potential problem with the RPI 3 and earlier that, under certain poorly defined conditions, can cause pops and clicks in USB audio. It's issue #2215 in the Raspbian kernel bug tracker. It isn't because the USB port is shared with the network connection - that's an often repeated myth. However I've never been able to reproduce it in PiCorePlayer so far - if they start including BruteFIR then that might change. In short don't worry unless you start hearing it, in which case the easy solution is to get a Pi 4.

'USB noise' is usually a modern presentation of a ground loop, but instead of a hum or buzz you get some sort of modulated noise. The Pi is no more prone to it than any other USB source, unless there are sources available with built in galvanic isolation. If home audio routinely used balanced interconnects it wouldn't be a problem. If you suffer from it your best bet is to follow a systematic process like the one in Jensen Transformers AN007.

Archimago has a number of tests on noise on the 5V line of various USB ports, including different ports on the same PC. The Pi is within the 'normal' range. It's part of any USB DAC's job description to deal with this as it's entirely expected. If it makes a significant difference then I'd argue the DAC is defective. Dongle style DACs get a bit of a pass here - they don't have room for much supply regulation, so may be more affected.

Search arstechnica.com for audiophile network cable to find the results of their series of tests, both controlled listening with a large number of subjects, and technical measurement of the cables. Short answer: no functional difference. Or just look at the error stats for the network interface after your Pi has been streaming (ifconfig or ip -s link show) - you probably won't have any errors.

Much (most?) audio streaming doesn't actually include retransmission as it would probably arrive too late to be used. In practice it's rarely a problem.

 

[abdo123]

Digital transport has been a solved issue for few decades now, all the noise claims have been completely bogus.

On the analog domain i would carefull about how long the cables are, and whether they're shielded or not. But that's pretty much it. I would only do this if there is an audible problem though.

 

[voodooless]

The audio file (FLAC, MP3...) consists of bits of data that needs to be passed in whole to the DAC. In case noise interferes with the message, polluted packets should be invalidated and sent again. The result being that the DAC would receive basically the entirety of the source file, and then it should be fully capable of converting it to Analog signal, with its given quality (precision of the clock, quality of the chip etc.). I'm pretty sure the bandwidth of USB is more than enough to absorb any overhead of sending the data twice if signal is really poor.

That is not quite how it works. First, your DAC does not receive a FLAC or MP3 file but just get's the raw PCM datastream. In most proper implementations the DAC will regularly request new packets of data. So the DAC dictates the speed based on the sample rate that is set. While there is error detection, error correction is not possible in this configuration. It would however be quite unlikely that any errors occur. They would also be very audible.

Noise can be an issue if the DAC is not able to isolate this noise and starts bleeding that into the output. Buy a better designed one..

I have the same question regarding high end expensive audiophile ethernet cables (although I don't want to open the Pandora box). Is it really necessary to invest in a 1000$/m ethernet cable when any cat6 cable can handle 1Gb/s and that TCP/IP protocol guarantees the integrity of the data?

You answered your own question . There is no reason whatsoever to spend any extra money on network cables especially for audiophile purposes.

 

[Sukie]

We probably ought to have an FAQ section for this.

Agreed. It does come up quite often.

 

[rwanou]

Thanks for the clarification.

There is a genuine potential problem with the RPI 3 and earlier that, under certain poorly defined conditions, can cause pops and clicks in USB audio. It's issue #2215 in the Raspbian kernel bug tracker.

So it is a driver issue, the way the OS manages the USB connection. If handled correctly, it shouldn't be a concern.

'USB noise' is usually a modern presentation of a ground loop, but instead of a hum or buzz you get some sort of modulated noise. The Pi is no more prone to it than any other USB source (...) It's part of any USB DAC's job description to deal with this as it's entirely expected.

First, your DAC does not receive a FLAC or MP3 file but just get's the raw PCM datastream. In most proper implementations the DAC will regularly request new packets of data. So the DAC dictates the speed based on the sample rate that is set. While there is error detection, error correction is not possible in this configuration. It would however be quite unlikely that any errors occur. They would also be very audible.

So the actual electrical 5V current from the output USB port could interfere with the analogical output. As you say, a well designed DAC should be able to filter electrical inferences and keep them away from the output signal...

Now a bonus question regarding PCM stream (I'll try to look it up on my own): Does the data stream contain both the time and the actual level value? My question being trying to assess the importance of the clock on a digital output device (or hat for the Pi). If the stream contains both info, then I guess the consumer can put off with some (light) timing incoherence. If the stream needs to be perfectly timed, then the clock form the source is absolutely essential, and needs to match (at least) the desired sampling frequency.

 

[voodooless]

The stream is not perfectly timed. The DAC will request new data in regular time intervals, And the source will need to feeds the data accordingly.

So If you play a WAV file, it's just streamed in chunks to the DAC's USB receiver. Clocking is done there. You are not dependant on any timing issues of the source (in so far as it needs to get the data in on time).

When playing audio files this works quite well. It's different when you have a live audio source that needs to go to the DAC. Then you have two competing timing sources, the ADC and DAC, and this can result in missing or duplicate samples. In those cases, they either sync the two up using the same master clock (for instance if they are the same USB device), or you'll need to use sample rate conversion to match it all up.

 

[threni]

We probably ought to have an FAQ section for this.

There is a genuine potential problem with the RPI 3 and earlier that, under certain poorly defined conditions, can cause pops and clicks in USB audio. It's issue #2215 in the Raspbian kernel bug tracker. It isn't because the USB port is shared with the network connection - that's an often repeated myth. However I've never been able to reproduce it in PiCorePlayer so far - if they start including BruteFIR then that might change. In short don't worry unless you start hearing it, in which case the easy solution is to get a Pi 4.

I've spent a fair bit of time playing the the Pi using either Volumio or various linux apps using Raspbian/Raspberry Pi OS. My main hifi is the Pi 4 with the latest Raspberry Pi OS, playing from a local 2" hard drive into a Topping E30, and my portable is a Pi Zero W with the latest Raspberry Pi OS into the Apple USB dongle (nanny state EU edition) playing from the SD card I boot from. Previously I've used the Pi 3. I've never, ever heard a single pop in any configuration unless:

1) I used Volumio, on the Pi 3.
2) I was copying music onto the attached 2" hard drive on the Pi 4 over wifi whilst listening to music.

So between my experience and reading the issue quoted above, I think it's highly likely that any pops are purely down to the puny cpu not feeding data to the DAC quickly enough, or getting interrupted in some way, but that this problem won't be limited to the Pi 3. Having said that, I've not noticed any popping recently (copying music whilst listening) which might have coincided with when I switched to using mpd as the player so it's possible that mpd is so efficient there's cpu to spare.

 

[somebodyelse]

@threni that's more or less what I thought until I actually tried reproducing it, then experimented with it. If you want to provoke the issue then start using BruteFIR - even with low cpu load. Then pin BrutreFIR to a single cpu core and hear it disappear. Certain workloads seem to provoke it, BruteFIR being one. I think Volumio and maybe Moode use another, but I don't remember what it was. I have tried and failed to provoke it in stock PiCorePlayer. If you find anything then the bug tracker is a more useful place for it than here.

 

[somebodyelse]

The stream is not perfectly timed. The DAC will request new data in regular time intervals, And the source will need to feeds the data accordingly.

And the pops and clicks are what happens when the source takes a fraction too long responding to the request and delivers the data too late.

 

[Katji]

I'd love to read some decent explanation on this matter.

https://www.xmos.ai/download/Fundamentals-of-USB-Audio(1.0).pdf
XMOS being the most common way. Doc explains timing/re-clocking and difference between file transfer and streaming.

[...]
Archimago has a number of tests on noise on the 5V line of various USB ports, including different ports on the same PC. The Pi is within the 'normal' range.

They vary. From no problem to problem. And some say [no problem] might be "you don't notice it until it's gone."
[If it really concerned me, I'd try swapping ports but...I like the way the cables are and I don't perceive a problem. I do know I have a proper cable, not a cheap cable from a phone accessory shop.]

It's part of any USB DAC's job description to deal with this as it's entirely expected. If it makes a significant difference then I'd argue the DAC is defective.

Some don't. ...Don't have suitable isolation. Some don't use digital noise isolators.
digital isolator chip - Google Search

Maybe part of what "DAC...the implementation" means.


USB cable specification specifies shielding.

 

[TheWalkman]

Hi All,

I'm soon to invest in an extra HiFi setup for my Corona Home Office, so I'm loosing some time on the forums trying to figure what my next DAC will be. I have a bunch of old Raspberry Pis rotting in the basement, and I thought I could re-use one of them to create an audiophile DAC. I already have 2 RPI with a Justboom AMP hat to power some integrated speakers in my home (1 stereo in the playroom, 1 divided into 2 mono entities for the 2 bathrooms). There is an extra Raspberry Pi zero with the Justboom DAC hat connected to my living room amp. Everything runs on PiCorePlayer, I'm quite happy with the result.

Now, I've been reading on this forum and elsewhere that the RPI 3 USB port is noisy. Apparently this is backed up with tangible measurements. But could someone explain the theory behind this noise? My limited knowledge has me thinking that a signal over USB is purely digital. Meaning that the quality of the transmission matters little as long as the message passes to its destination. The audio file (FLAC, MP3...) consists of bits of data that needs to be passed in whole to the DAC. In case noise interferes with the message, polluted packets should be invalidated and sent again. The result being that the DAC would receive basically the entirety of the source file, and then it should be fully capable of converting it to Analog signal, with its given quality (precision of the clock, quality of the chip etc.). I'm pretty sure the bandwidth of USB is more than enough to absorb any overhead of sending the data twice if signal is really poor.
I have the same question regarding high end expensive audiophile ethernet cables (although I don't want to open the Pandora box). Is it really necessary to invest in a 1000$/m ethernet cable when any cat6 cable can handle 1Gb/s and that TCP/IP protocol guarantees the integrity of the data?

I'd love to read some decent explanation on this matter.

Rwanau,

Just posted some thoughts on the other Pi thread. https://www.audiosciencereview.com/...pi-as-a-music-server.9130/page-12#post-658318 Post #233

Executive summary. Don't overthink this. To my ears, virtually any Pi Streamer sounds good. The USB issue is a non-issue for me.

 

[rwanou]

Rwanau,

Just posted some thoughts on the other Pi thread. https://www.audiosciencereview.com/...pi-as-a-music-server.9130/page-12#post-658318 Post #233

Executive summary. Don't overthink this. To my ears, virtually any Pi Streamer sounds good. The USB issue is a non-issue for me.

Thanks Actually I just received the HifiBerry DAC2HD. As you suggested, I did not spend endless nights choosing a solution. I'm waiting to get my delivery of fresh Pis 4. But I won't pair the DAC with a Pi4, because I think it is overkill for PiCorePlayer, instead I'll reuse one of the spare Pi 3 that I'm freeing up for the streamer. A standard Cat6 cable is already in place for network (because we all know that WiFi is bad for sound ).

The goal of this thread was really for me to get more understanding of what is going on with USB/DAC setups in theory, as the title suggests.

 

[TheWalkman]

Thanks Actually I just received the HifiBerry DAC2HD. As you suggested, I did not spend endless nights choosing a solution. I'm waiting to get my delivery of fresh Pis 4. But I won't pair the DAC with a Pi4, because I think it is overkill for PiCorePlayer, instead I'll reuse one of the spare Pi 3 that I'm freeing up for the streamer. A standard Cat6 cable is already in place for network (because we all know that WiFi is bad for sound ).

The goal of this thread was really for me to get more understanding of what is going on with USB/DAC setups in theory, as the title suggests.

Enjoy!

 

[rwanou]

Enjoy!

Cheers!

Oh, and to be complete, my music is all on one NAS, mounted with NFS on my PiCoreMaster, which runs LMS. Some is MP3/AAC, some is FLAC, some is Apple Losless. At some point I had a system of parallel folders for the music in FLAC 24/92, as it is not supported by iPhone. I ended up giving this up as it was too much hassle and all music is now CD quality or lower. I might subscribe to Qobuz if the 1 month trial proves worthy and profit high res audio.

 

[Foxenfurter]

I had a Pi2 and a Pi3B. I have only run picoreplayer and squeezelite using the ethernet interface for data and LMS on a separate server.
When I ran an old Isochronous dac on the Pi2 I experienced no dropouts clicks or pops. But with an XMOS dac asynchronous would result in a lot of ticks and clicks, which progressively got worse. I tried various products to "clean up" the USB source but they did not make a difference.

With the Pi3 different story when I used picoreplayer 3 into the XMOS DAC I very occassionally got ticks these completely went when I updated to Picoreplayer 4 and I have not experienced them since.

So in summary unless you are running a very old Pi on an old version code, you should be fine. You won't hear distortion or noise (subject to your other components) only dropouts and these sound similar to minor ticks that you can get playing vinyl.

 

[thetrystero]

Archimago has a number of tests on noise on the 5V line of various USB ports, including different ports on the same PC. The Pi is within the 'normal' range. It's part of any USB DAC's job description to deal with this as it's entirely expected. If it makes a significant difference then I'd argue the DAC is defective. Dongle style DACs get a bit of a pass here - they don't have room for much supply regulation, so may be more affected.

@somebodyelse I'm looking in to a streaming solution where I can use the smsl su-8 v2 balanced dac and was thinking about the rpi4 until I read about all this usb noise issues. I am concerned about the impact that the rpi4 will have on the SINAD of the overall chain. If I've been reading it correctly, "transports" like the allo digione or usbridge are added to the rpi4 with the claim of reducing noise at the connection between the dac and the rpi4 is that right?

If I'm reading your comment right, it sounds like the dac will already handle this noise and just going from the rpi4 straight in to the dac will have zero impact on the SINAD of the overall chain, is that correct, without the need for any such "transports"?

 

[somebodyelse]

The DigiOne or Usbridge may make a difference if you've got a badly designed DAC that's sensitive to jitter in spdif signals or to noise in USB power lines, but a properly designed modern DAC won't be sensitive to either. If you have a look at the Modi 2 review you'll see why Allo picked that one to demonstrate the benefits of the Usbridge - the Modi 2 is sensitive to USB noise like no other DAC tested so far, and gets called out for it. You'll see no such sensitivity on the SU-8 v2 review, so no reason for a Usbridge. SPDIF jitter sensitivity is similarly a solved problem for most DACs now, with the occasional counterexample to show why it's still worth testing.

 

[mikeburns]

@somebodyelse I'm looking in to a streaming solution where I can use the smsl su-8 v2 balanced dac and was thinking about the rpi4 until I read about all this usb noise issues. I am concerned about the impact that the rpi4 will have on the SINAD of the overall chain. If I've been reading it correctly, "transports" like the allo digione or usbridge are added to the rpi4 with the claim of reducing noise at the connection between the dac and the rpi4 is that right?

If I'm reading your comment right, it sounds like the dac will already handle this noise and just going from the rpi4 straight in to the dac will have zero impact on the SINAD of the overall chain, is that correct, without the need for any such "transports"?

The smsl su8 works great with a pi streamer and it sounded so great. I did have an issue with the pair in that the su8 powers down the USB port when you turn on another input (mine did at any rate). This meant that my pi streamer using moode struggled to reconnect with I went back to USB. If you were only going to use USB and not other connections then they will behave well together. I loved the su8 other than that issue. It was bad enough that I moved to a minidsp shd which keeps the USB live. This fully resolved my issue. The pi itself was wonderfully clean with the su8. Transparent even haha.