We are talking about binary data. Asynchronous USB (any decent USB DAC uses this) is a reliable interface with retransmits. Its like TCP/IP. When you browse the web the data arrives bit perfect from anywhere in the world and we are talking potentially thousands of miles of cables, some of them under the oceans. USB DACs and network streamers usually buffer the incoming stream and reclock. This is just normal and no data is lost.
I don’t quite get this point about a “long way” affecting the digital signals. Someone care to explain? What am I missing?
I suspect that this is a language issue here. USB is well documented to be length limited (have a search). That’s not what the documentation is talking about: it reads to me that all the interconnections may well affect the data stream’s integrity. I’ve no idea if this is the case; I’ll leave that to those more knowlegeable
If I take a stab at explaining Michelangelo’s use of English (which is wa-a-a-y better than my Italian), I’d suggest that the point he’s making is not in the detail of the signal processing involved with USB sound but only that the USB signal path, especially the RPi USB signal path, sucks by comparison with the more direct signal path when using I2S. I doubt that he’s getting into the more obscure nonsense such as special USB cables only for audio (see audiosanctuary.co.uk/hifi-us … ained.html for one such attempt), rather that he’s pointing out the USB path is far more likely to corrupt the signal. Really don’t think he’s going into woo territory for digital signalling
You are mostly right when talking about the use of an asynchronous USB feed into the DAC. Although this way of feeding the signal to the DAC is still prone to interference (see 1 below), it is probably the best path for an external DAC as the DAC should take care of the correct timing/clock (see 2 below) as you explain.
But, the Pi is not capable of feeding a DAC a proper async feed as the USB interface is an USB-on-the-go type and not a proper full fledged USB 2.0 interface. Also speed/interrupt wise, the Pi can not keep up to get the data fast enough onto the USB interface which causes data underruns (meaning skipping data to not get to far behind).
If you want to benefit from a good external DAC that support async USB, your best bet would be to run Volumio x86 for example on capable hardware.
Back to the Pi and why the short path in the blog makes sense. There are two ‘common’ problems which always cause a lot of debate between real audiophiles (which I am not really) and more digital orient people (which was me ). Google around and you can find thousands of articles discussing these. But I will try a short summary.
Interference/bit ‘flipping’
In electronics (and also IC’s for that matter), real zero’s and ones do not exist. They are just represented by agreements on interpreting current/voltage levels of analog signals. And this is were issues can arise. Each signal path (piece of cable/wire) or circuitry handling such a signal uses current on its own to operate and each current flow radiates somehow. This radiation (or multitude of different radiations coming from different parts of the system) can cause interference on a circuitry or signal path which might cause the current/voltage of a certain part/path to get modified. This can cause that the original signal (say representing a digital zero) now has a different current/voltage level than what was originally intended and might get interpreted differently at the receiving end (the same digital zero now is interpreted as being a digital one). This bit ‘flipping’ (or corrupting, whatever you call it) is a problem of interference in the digital domain. Same applies for the analog domain of music signal, but the effect of interference is different, most likely even bigger.
This is why there is some much going on about type of cables being used, shielding circuitry, different ways of grounding equipment and signals, different types of power supplies, etc. All about trying to minimize interference in both the digital- and analog parts of an audio setup.
Timing/clocks
If you are not using an external DAC that is capable of receiving an async data feed and doing its own clocking of the signal, you will be using some other DAC that depends on the ‘timing’ of the data feed to do its timing/clocking. Getting the correct zero’s and ones is one thing, but almost as important (and some even argue that it is more important!) is getting a good clock signal to adequately reproduce an analog signal. The period of time in nano-seconds between each data packet received is the bases for the duration of a certain level in the analog signal. This timing ‘data’ is not part of the (sample) data itself but reflected by the in between time periods of the actual data.
The accuracy of this timing ‘data’ is determined by the accuracy of each involved circuitry that is part of the digital chain. So each conversion from one type of transport to another (for example from I2S to SPDIF to Optical SPDIF and back at the DAC) can cause the timing ‘data’ to get altered resulting in a less accurate analog reproduction.
Unfortunately, the Pi is not a very good clock source (thats where a products like the Kali or Hifiberry boards with own clocks comes in) and having multiple conversion do not improve the accuracy of the timing ‘data’.
So if you can keep a signal path and amount of involved circuitry as short/low as possible, it helps reducing the possible pieces that can cause interference and/or timing issues.
Hopefully the above gives some more info on the background of the Blog post.
Thank you Patrick for the detailed response. I did not know that the Pi uses an “on-the-go” USB interface. I will have to read the RFC for that and compare with that of standard asynchronous USB specification. Most interesting will be if the on-the-go USB interface supports reliable delivery.
Re: 1) If the interface is reliable, the “bit flipping” theory might apply, but if it is reliable, then there the digital domain that abstracts the underlying transport should abstract away the issues of voltage fluctuations. In other words, with checksums and retransmits, either you get the correct 0s and 1s, or you get nothing. Also note that if the bits did get flipped and were converted to analog, the result could be garbled audio. If the MSB gets flipped, it is very likely that it will manifest itself quite conspicuously in the audio output. This will not be in the form of worse sound quality, this will be some junk that does not sound like music at all. Imagine a sine wave and then imagine it being distorted unpredictably.
Re: 2) If the incoming data is buffered and reclocking is done off of that buffer, the length of the chain behind that buffer is irrelevant. Note that the reclocking will be true to the data that is in the buffer and it cannot control whether the data arrived correctly. Now the path between reclocking and actual D-to-A conversion should probably be as short as possible and this is where I think a good design comes into play. A good DAC implementation should handle buffer underruns elegantly; lack of data should result in an audio drop-out, not lower sound quality.
