03-Feb-2016, 15:57
Nice post Pim. Always interesting to hear about what other people do for a living (especially if it's engineering -- I am biased!).
Picking up on one point you mentioned: error detection and correction.
My understanding of USB (having written host and peripheral drivers for USB audio among other things) is that each USB packet carries a CRC which enables the receiver to determine whether or not the packet has been received correctly (all bits as transmitted). In other words, errors can definitely be detected. However, as far as I know the USB audio standards do not define a mechanism for error correction (other standards, for example mass storage, do define error correction methods). Putting this into real-life terms, if a DAC receives a bad packet, it know about it but is then on its own in deciding what to do -- maybe output silence for the short period corresponding to the incorrect packet, or maybe do something more sophisticated.
Also, when I hear statements about signal rise time affecting jitter, I am sceptical in the extreme. Maybe that was/is/can be true with something like S/PDIF, but there are so many more hardware and software layers involved in USB that by the time the payload reaches something that actually knows what to do with it (i.e. play it as audio) the original clock timing is long gone. (I am not talking about clock drift, which is a significant concern, but short-term jitter e.g. between samples.) All USB controllers that I've worked with transfer data from the wire into memory in chunks of words, maybe whole packets at a time. Any relative timing between arrival of individual bits from the wire is surely lost during that process.
The same thing is broadly true of wired Ethernet, except that some of the higher-level protocols (such as TCP) do include mechanisms for error correction.
It should be no surprise that both these protocols have (at least) error detection capabilities, because otherwise they would be unreliable for general use. We don't agonise over whether "bits are bits" when we connect a disk drive to a computer or use file transfer protocol to send a file across the Internet, precisely because the relevant protocols are engineered to detect errors and correct them, one way or another.
Having said that, I can see mechanisms by which a USB- or Ethernet-connected audio system could be affected by subtle behaviour depending on what cable is used. The most obvious one (to me at least) being injection of noise via the power and ground and/or due to switching currents. These are analogue effects, of course. And I don't see how one could generalise about whether or not they are audible as I'd expect the effects to depend substantially on the design of both "ends" (e.g. computer and DAC, streamer and Devialet, ...) as well as the connecting cable.
I'll be really interested to follow your experiment. One other thing, though: I wouldn't under-estimate the power of expectation bias, even if you try to take it into account
Picking up on one point you mentioned: error detection and correction.
My understanding of USB (having written host and peripheral drivers for USB audio among other things) is that each USB packet carries a CRC which enables the receiver to determine whether or not the packet has been received correctly (all bits as transmitted). In other words, errors can definitely be detected. However, as far as I know the USB audio standards do not define a mechanism for error correction (other standards, for example mass storage, do define error correction methods). Putting this into real-life terms, if a DAC receives a bad packet, it know about it but is then on its own in deciding what to do -- maybe output silence for the short period corresponding to the incorrect packet, or maybe do something more sophisticated.
Also, when I hear statements about signal rise time affecting jitter, I am sceptical in the extreme. Maybe that was/is/can be true with something like S/PDIF, but there are so many more hardware and software layers involved in USB that by the time the payload reaches something that actually knows what to do with it (i.e. play it as audio) the original clock timing is long gone. (I am not talking about clock drift, which is a significant concern, but short-term jitter e.g. between samples.) All USB controllers that I've worked with transfer data from the wire into memory in chunks of words, maybe whole packets at a time. Any relative timing between arrival of individual bits from the wire is surely lost during that process.
The same thing is broadly true of wired Ethernet, except that some of the higher-level protocols (such as TCP) do include mechanisms for error correction.
It should be no surprise that both these protocols have (at least) error detection capabilities, because otherwise they would be unreliable for general use. We don't agonise over whether "bits are bits" when we connect a disk drive to a computer or use file transfer protocol to send a file across the Internet, precisely because the relevant protocols are engineered to detect errors and correct them, one way or another.
Having said that, I can see mechanisms by which a USB- or Ethernet-connected audio system could be affected by subtle behaviour depending on what cable is used. The most obvious one (to me at least) being injection of noise via the power and ground and/or due to switching currents. These are analogue effects, of course. And I don't see how one could generalise about whether or not they are audible as I'd expect the effects to depend substantially on the design of both "ends" (e.g. computer and DAC, streamer and Devialet, ...) as well as the connecting cable.
I'll be really interested to follow your experiment. One other thing, though: I wouldn't under-estimate the power of expectation bias, even if you try to take it into account
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
