About USB cables in general

[Brillo]

There is a lot of knowledge surfacing on the 'bits are bits' thinking now. I suggest you also read a little bit of that. Then you can return with an extended knowledge on how it all works.

That’s good to know. Please can you supply links to these knowledge sources?

I ask because my general view sides with the OP. I have always been a sceptic but recently bought a reasonable quality USB cable and I was convinced it improved the sound. My ITC friend rubbished my perception. I’m now in a quandary as to whether that was an ‘expectation bias’ experience or whether it really did make a difference.

Like, I expect, every other streaming listener, I just want to create the best sound to listen to, so look forward to your reply. No axe to grind here. I just want straight facts and information.

One thing I like about being an engineer is learning about new and interesting topics, and having my firmly held ideas challenged by new research. I usually squirm a bit when I hear/read something like what Greg posted: knowledge sources, straight facts and information are at your fingertips, and asking others for them sounds like a case for lmgtfy.com! It is just as easy to search for information about the USB protocol, physical layer and testing tools as it is to search for audiophile quality high end USB cables (wired in the right direction, of course). This being said, there are some cases that are a bit more nuanced... I feel this is one of them.

When confronted with an engineering problem, I like to keep in mind that the way you ask the question can influence the outcome, as can the scope of the answer (a nice example here). In this case, you could limit the answer to "is bits are bits a valid argument", i.e. can a USB cable's intrinsic "quality" influence the values of PCM samples coming out of a USB audio receiver device? You could also go a step further and add time information – can the cable influence the USB interface timing? But then you have to ask, does the jitter on an asynchronous USB link get passed through to the synchronous PCM output?.

The first part – is it true that bits are bits –  is not too hard to answer. This can effectively be described as stated, i.e. packaged "fancy" water being transported by a vehicle, but there is an additional variable, the USB packet CRC code. This can be painted in the ongoing narrative as a shock indicator and safety seal. How do you know not to trust a bottle that's been handled roughly? If the shock indicator on the packaging (the CRC of the USB packet) is red or if the safety seal is broken, you can safely assume that the package has been handled roughly and should not be accepted. If this is the case, the receiving party does not sign for the package (does not ACK in the USB protocol) and the package must be sent again. This goes on until the package arrives in good condition. Will deliveries made by a Mercedes be refused less frequently than those made by a Fiat? Probably not... As long as the cable meets the specified differential impedance or 90Ω, maximum propagation delay of 27ns, and maximum propagation skew of 100ps between the differential lines (such as this one), everything should be more than fine, and the USB driver and receiver electronics are probably mush more prone to behaving badly. Also, the CRC error rate is easily measured by any USB protocol analyzer (see here), so there is very little room for interpretation. Plug a cable into an analyzer setup and see if is induces errors. And so what exactly does happen if packages start getting refused? The bitrate is reduced since time has to be spent resending packets. Is this reduction audible? If things get bad enough, the USB link will be closed since the protocol has faulty device detection built in, or drops will occur and yes, that is definitely audible. Other than that, the bits will come out exactly as they went in.

So what about timing? This is quick: the answer is no. First, all dedicated USB audio chips I've used (such as this or this) have dedicated external media clocks. For software based systems, the media clock is generated by the CPU core clock (more exactly the system's wall clock). The USB clock is not recovered as it would be in an AES-3 link (S/PDIF, etc.). Second, jitter introduced by a (passive) cable is deterministic and will not affect anything if within the tolerances of the USB spec, which are quite generous.

So that's it? Well, if it were that simple, I'm not sure there would be so many "high end" cable manufacturers around... You could also extend the investigation to parasitic analog effects. Can the USB cable inject RF or EMI noise into a system? If so, what level of noise on the output would constitute an audible effect? 3dB below the system's self noise? 100dB below? And how do you decide on what level of RF and EMI noise to subject your setup to? What is the noise profile? Narrow band? Wide band? What frequencies are audible? If you superimpose 2.4 GHz on your audio ground, does it introduce something you can hear in the acoustic signal coming from the speakers? Then you can start asking even more questions – If the USB cable has a poor shield, the differential data pair and the receiver chip's CMRR will have to be slightly better, but won't less noise be coupled through to ground? It depends. Is the source device dumping junk through the shield to the downstream device? It depends. Will the inherent "quality" of the cable alter the way all of these things interact? It depends. And since "it depends", there's room for magic (read "marketing"). 

So does the quality of the cable's shield make a difference? The answer is more complicated, but probably "no". The way grounding affects noise in a system is almost entirely dependent on the design of the receiver's electronics, not the cable attached to them. Of course, a defective or just plain "bad" cable (e.g. not correctly shielded, extremely long, impedance way out of spec...) can cause strange things to happen, but in order to not stray too far we will assume here that that is not the case. (Using our delivery vehicle analogy, just avoid square wheels on the delivery truck, or trying to deliver a shipping container with a bicycle.)


Oh well, I had nothing else to do on a Sunday afternoon...