• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

Do USB Audio Cables Make A Difference?

chris719

Active Member
Joined
Mar 22, 2019
Messages
285
Likes
249
To backup your words: "If the CRC is not correct, the transfer is not acknowledged and will be retried. If the device is not ready to accept data it can send a negative-acknowledgment, NAK, which will cause the host to retry the transfer", source: https://www.xmos.ai/download/Fundamentals-of-USB-Audio(1.0).pdf
This is not true for 99% of USB Audio Class devices. It only applies to bulk transfers, not isochronous transfers.
 

trl

Major Contributor
King of Mods
Joined
Feb 28, 2018
Messages
1,452
Likes
1,529
Location
Iasi, RO
Then you might need to elaborate a bit here, otherwise some might think that some bits might get lost during the transfer and audio will get affected (like UDP transfer on audio-video files when skipping frames). Thanks!
 
Joined
Apr 28, 2021
Messages
59
Likes
20
This is not true for 99% of USB Audio Class devices. It only applies to bulk transfers, not isochronous transfers.
Which is true but won't result in any positive effects on the sound. To modify the streamed data to achieve any desired changes (sound enhancement) bits at specific positions withon the data stream need to be flipped. Problem for the external hardware trying to do this: it doesn't know where to change the data. It is a constant stream of bits, without header or other hints. And on top, even if this device manages to manipulate the data in such a stream, the same approach would end in a chaos as soon as the user changes the data transfer protocol or even the quality/bitrate.

So if you can hear music while streaming a song, open the configuration of the streamer (e.g. in Windows under audio devices), change bitrate or frequency, play another song and still can hear something, your cable or PSU has no effect.

And if you want to be sure, then play one of these MQA coded files. The cable would have to know more than anyone knows outside of the company to alter the data in such a stream.
 

trl

Major Contributor
King of Mods
Joined
Feb 28, 2018
Messages
1,452
Likes
1,529
Location
Iasi, RO
From what it seems, isochronous transfer is prone to jitter and to packet loss too, so getting closer to the initial question now: could a wrongly designed USB cable or a defective one alter the USB transfer is such a way that some bits to actually get lost? Will this affect the output audio in any way?

I think that theoretically the above assertions might be possible, although in all objective tests I've seen even the cheapest cable was able to deliver the same accuracy as an expensive one.
 

chris719

Active Member
Joined
Mar 22, 2019
Messages
285
Likes
249
Then you might need to elaborate a bit here, otherwise some might think that some bits might get lost during the transfer and audio will get affected (like UDP transfer on audio-video files when skipping frames). Thanks!
I don't know if I need to elaborate, they can get lost. It will be obvious and manifest as pops, clicks, etc. if enough are lost. It's very much like UDP.
 

trl

Major Contributor
King of Mods
Joined
Feb 28, 2018
Messages
1,452
Likes
1,529
Location
Iasi, RO
It will be obvious and manifest as pops, clicks, etc.
Makes sense, but how can this be catch with an AP or another audio measurement device? Or better: how can we find such a poor USB cable to do the measurements?
 
Joined
Jan 25, 2021
Messages
25
Likes
11
You now have them 'rolling' optical transceivers like they are running tubed gear. And the claims are all the same about PRAT, bass, imaging. It's so bonkers because they couldn't do a minimal L2 switch config if their lives depended on it.
That's a new one to me. So are you talking inside the DAC, on the receiving end of the fiber connection?
 

chris719

Active Member
Joined
Mar 22, 2019
Messages
285
Likes
249
Makes sense, but how can this be catch with an AP or another audio measurement device? Or better: how can we find such a poor USB cable to do the measurements?
Dropped samples are incredibly obvious in an FFT plot. Producing this condition organically would be hard. The line between fully working and not working at all is incredibly small.
 

KSTR

Major Contributor
Joined
Sep 6, 2018
Messages
1,080
Likes
2,299
Location
Berlin, Germany
A while ago I made a test to see how bad a cable must be until you get transmission errors etc:
1620156437916.png

A data line (the green wire) was singled out and brought near a ferrite core to create a huge impedance mismatch. During plug-in, the ferrite was removed so that no problems occur. Then, during audio playback, I located the green data line closer and closer to the ferrite until I heard short dropouts (clicks & pops, the strength and the repeat rate depended on the ASIO buffer size).
Only a tiny bit closer and the whole communication breaks down and the device goes offline. It was basically impossible to keep transmission going and have enough dropouts at the same time. It's a very sharp transition from 100% go to total no-go.
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,404
Likes
7,415
Location
Hampshire
Dropped samples are incredibly obvious in an FFT plot. Producing this condition organically would be hard. The line between fully working and not working at all is incredibly small.
Connect a variable capacitor between the data lines and turn it up gradually while playing audio. At some point, the sound will start crackling, and shortly thereafter it will cut out completely.
 

chris719

Active Member
Joined
Mar 22, 2019
Messages
285
Likes
249
Connect a variable capacitor between the data lines and turn it up gradually while playing audio. At some point, the sound will start crackling, and shortly thereafter it will cut out completely.
Have you tried it? Might be tough to get it to enumerate and behave correctly with the cap in there even turned to minimum value?
 

dc655321

Addicted to Fun and Learning
Joined
Mar 4, 2018
Messages
794
Likes
915
I wrote a short script a while back in response to someone thinking flipped bits could be a subtle, even pleasant thing.

The script randomly flips bits in a track segment. Not pleasant at all, obviously...

Will post script and results when I get a few moments. "Working" right now...
 

KSTR

Major Contributor
Joined
Sep 6, 2018
Messages
1,080
Likes
2,299
Location
Berlin, Germany
Cap between D+/D- is probably easier to dial into the critical zone. Will try that, and also try what I outlined here, that is, check if it is actually possible to get corrupted samples rather than full blocks zeroed out. As CRC is still applied in isochronous (but no re-send initiated), I think this will be extremely unlikely. One would need to alter enough bits at the correct places that the CRC misses it and those bits must be in the payload section of the packets. Close to impossible, I'd say.
 

DonH56

Major Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
5,023
Likes
8,536
Location
Monument, CO
I don't know anything specifically about USB SerDes. For others I have known, the receiver usually works right to the limit, then fails spectacularly with miniscule transition band. Modern receivers are pretty advanced and great at pulling signals out of the noise. With all the various front-end variable gain and EQ stages (VGA, AEQ, CTLE, DFE -- all sorts of alphabet soup in my world, and probably for USB Rx as well), there is almost nothing between perfect recovery and complete failure to capture valid data.
 

chris719

Active Member
Joined
Mar 22, 2019
Messages
285
Likes
249
Cap between D+/D- is probably easier to dial into the critical zone. Will try that, and also try what I outlined here, that is, check if it is actually possible to get corrupted samples rather than full blocks zeroed out. As CRC is still applied in isochronous (but no re-send initiated), I think this will be extremely unlikely. One would need to alter enough bits at the correct places that the CRC misses it and those bits must be in the payload section of the packets. Close to impossible, I'd say.
I have an LTC2387 ADC that I have acquired audio with just for fun at 15 MHz sample rate. I had some lost samples in the setup due to a bug with a driver (1 sample lost every 4096 samples). It wasn't really audible after I downsampled to 192 kHz with SoX and played it back. It did show up in the spectra, though. That is 1 sample lost at 15 MHz though... significantly less bad than losing a sample at audio rates.
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,404
Likes
7,415
Location
Hampshire
Have you tried it? Might be tough to get it to enumerate and behave correctly with the cap in there even turned to minimum value?
I have tried it. The cap I used has a range of about 5 pF to 500 pF. I don't remember at what point the connection broke down.
 

KSTR

Major Contributor
Joined
Sep 6, 2018
Messages
1,080
Likes
2,299
Location
Berlin, Germany
@chris719, RME's ASIO driver most certainly is bug-free. ;-)
With the feedback mechanism in asynchronous isochronous transfer, as far as I can see, the device always knows how many samples will arrive per packet even when it instructs the host to temporarily increase or decrease the current count per packet. I've clocked the RME in USB mode externally from the AP via TOSLINK with more than 10% clock rate mismatch without problems, so the feedback clearly is working properly even for a gross mismatch.
 

trl

Major Contributor
King of Mods
Joined
Feb 28, 2018
Messages
1,452
Likes
1,529
Location
Iasi, RO
A while ago I made a test to see how bad a cable must be until you get transmission errors etc:
View attachment 127921
A data line (the green wire) was singled out and brought near a ferrite core to create a huge impedance mismatch. During plug-in, the ferrite was removed so that no problems occur. Then, during audio playback, I located the green data line closer and closer to the ferrite until I heard short dropouts (clicks & pops, the strength and the repeat rate depended on the ASIO buffer size).
Only a tiny bit closer and the whole communication breaks down and the device goes offline. It was basically impossible to keep transmission going and have enough dropouts at the same time. It's a very sharp transition from 100% go to total no-go.
Great work! Any chance to get a jitter test and an FFT with this "cable"?
 

KSTR

Major Contributor
Joined
Sep 6, 2018
Messages
1,080
Likes
2,299
Location
Berlin, Germany
@trl, J-Test is generally useless on USB, and even more so with that kind of DAC (asynchronous isochronous), the DAC is the clock master at all times.

For the same reason any other measurement on output signal will not show even the tiniest difference -- up to the point where samples are actually dropped (and zeroed). As long as the incoming data is correct and complete the DAC's output will be perfect, no matter how "almost broken" the USB low-level communication is, on the hardware level.

For this specific DAC (RME ADI-2 Pro, notably with the latest firmware), you wont't even see any kind of ill-effect even when it is forced to operate on a massively jittered SPDIF/TOSLINK signal, and with "massive" I mean many orders of magnitude more of jitter that any real-world source would ever have.
 
Top Bottom