More USB

[Purité Audio]

I presume the slight differences in level are down to the various cables electrical parameters or is there something fundamentally wrong with his method?

Keith

 

[DVDdoug]

or is there something fundamentally wrong with his method?

I can't watch the video now but if they are showing a difference, something is wrong with the cable or something's wrong with the test.

USB is digital... Numbers... You can send your bank balance over a USB connection a million times and it's not going to off by 1-cent. Or if something is bad or flakey and you get do an error, a billion dollar error is just as likely as a 1-cent error.

 

[Gregss]

I can't watch the video now but if they are showing a difference, something is wrong with the cable or something's wrong with the test.

USB is digital... Numbers... You can send your bank balance over a USB connection a million times and it's not going to off by 1-cent. Or if something is bad or flakey and you get do an error, a billion dollar error is just as likely as a 1-cent error.

Hello,

Agree totally. Almost funny how the only people who are having problems with USB cables are those selling expensive ones. Work just fine for everyone else.

Greg

 

[fieldcar]

fundamentally wrong with his method

Yep. Since he just recorded a loopback from the DAC to an ADC, the sample time periods will not line up relative to the waveform of the audio. You cannot time-align analog audio by samples and expect a perfect null to happen unless you record at a very high sample rate or oversample the recordings. The result should only be electrical noise from the DAC to ADC signal path.

As always, an elusive Monty pops up to save the day. See 4:48 and 20:30 for a good explanation.

 

[Cbdb2]

More BS from an Dunning–Kruger.
Didn't want to waste 30 minutes. Skipped thru parts. The video is called objective, than at 24:00 he says "one of the cables had a better sense of body and warmth" and then more subjective BS. Then excuses for more testing, like his theory that RF interference is the cause. (very easy to test). Then at the end he says he previously "reviewed" a bunch of aufioquest usb cables and they all sounded different, but the cheaper ones sounded better. Don't waste your time, theres nothing to see.

 

[mansr]

is there something fundamentally wrong with his method?

The comments under the video suggest that there is (improper alignment being the most obvious). I'm not going to waste my time watching it.

 

[KSTR]

or is there something fundamentally wrong with his method?

Yes it is.
Direct subtraction is very tricky, that's why people spent man-years on algorithms that actually give correct results. DeltaWave (https://deltaw.org/) is the only reliable subtraction tool atm.

And even with DeltaWave you must run baseline checks like recording with the same cable several times (at different times). Four runs minimum, to establish the baseline difference. Only when the differences between different cables (again several runs) are systematically larger than this baseline one may conclude the cable actually made a difference. Since it's USB, only secondary effects can be resposible for any difference as the DAC always got bit-identical data each and every time.

Other than differences in mains hum/buzz etc I've never managed to find any difference in USB cables, even broken ones (skewed impedance to the point that communication almost breaks down).

 

[fieldcar]

I'm not going to waste my time watching it.

But he has a British accent like goldensound, so you need to be swooned and enamored!

 

[ZolaIII]

It can be done again in more controlled conditions with verified equipment (scientific experiment).
He did make a methodological error. If hypothesis that output signal is same with all cables fails you use original source master for comparison not an output from generic USB cable. Of course every deviation from master is considered as distortion (so you calculate where there is least difference). If there is a difrence it's tied to IMD and tied to EMI and cable length of course.

 

[JayGilb]

USB data sends audio data as an isochronous packet and it is considered time sensitive, so no CRC checking or retransmission occurs.
The same packet is resent until the transmitter receives an ACK reply.
Clock sync data and control packet transfers are of an interrupt nature and use a CRC to verify data integrity.
Audio data is considered non-critical, so bit perfect transmission is not guaranteed.

Add to that, his USB root hub maybe sharing processor interrupts with other active I/O devices and with USB's time sensitive nature, data can be
dropped leading to his null test showing leakage.

 

[Jinjuku]

Read some of the comments and this 'youtuber' doesn't understand he's dealing with generational copies?

You don't get this delta with one time D/A and measuring that.

I didn't know DarqueKnight was an Aussie.

 

[Jinjuku]

USB data sends audio data as an isochronous packet and it is considered time sensitive,

Are you sure about this? Async DAC's have been a thing for ~14 years or so.

 

[Jinjuku]

Audio data is considered non-critical, so bit perfect transmission is not guaranteed.

Again I think you have a misunderstanding. USB doesn't have QoS markings like Ethernet does. And even Ethernet with QoS will still deliver the payload 100% bit perfect. Just may not be on the schedule you want.

 

[Kijanki]

Most of USB today is asynchronous meaning that D/A conversion clock is independent from incoming sample rate, and as such, there is no samples to align. What is being transmitted over USB is plain data - time is not involved. Data is send in "frames" containing many samples at lower frequency - likely around 1kHz. DAC places samples in the FIFO (first in - first out) buffer. In order to align incoming samples with D/A conversion rate incoming number of samples has to be adjusted. DAC sets some safe level of data remaining in the buffer, for instance 50% and signals back buffer under/overflow signal/flag. Upon status of this flag computer adjusts number of samples in the next frames. That way computer can prevent missing samples. With this method the only thing that can influence the sound is electrical noise injected by the cable, that can affect internal clock timing (jitter) and analog circuitry. This noise can be coming from computer or picked-up by the cable. Filtering of digital noise, optical isolation (if DAC doesn't have one) and cable shielding will help, but it has nothing to do with actual samples being delivered in perfect fasion.

 

[JayGilb]

Again I think you have a misunderstanding. USB doesn't have QoS markings like Ethernet does. And even Ethernet with QoS will still deliver the payload 100% bit perfect. Just may not be on the schedule you want.

I'm just stating that bit perfect transmission is not guaranteed.

 

[Jinjuku]

I'm just stating that bit perfect transmission is not guaranteed.

And I'm stating you don't know what you are talking about. If we run with your supposition then you can't be guaranteed that the copy of a file you made to a USB thumb drive had the same MD5 checksum. But yet it does.

This is why you can see a download of a 3GB file, they include the hash, so when you get it on your side you can hash the file and come up with they same number.

You need to understand you have a misunderstanding.

 

[JayGilb]

And I'm stating you don't know what you are talking about. If we run with your supposition then you can't be guaranteed that the copy of a file you made to a USB thumb drive had the same MD5 checksum. But yet it does.

This is why you can see a download of a 3GB file, they include the hash, so when you get it on your side you can hash the file and come up with they same number.

You need to understand you have a misunderstanding.

I'm referring to USB audio data type packets.

 

[mansr]

Are you sure about this? Async DAC's have been a thing for ~14 years or so.

Standard USB audio uses isochronous transfers in async/adaptive mode. Isochronous endpoints have pre-allocated bandwidth to avoid contention with bulk transfers. If an isochronous packet has a CRC error, this is detected, but there is no retransmission. Bulk transfers have guaranteed delivery with retries until the CRC check passes. This means there are no guarantees regarding bandwidth or latency, making it unsuitable for many audio applications.

 

[Jinjuku]

Standard USB audio uses isochronous transfers in async/adaptive mode. Isochronous endpoints have pre-allocated bandwidth to avoid contention with bulk transfers. If an isochronous packet has a CRC error, this is detected, but there is no retransmission. Bulk transfers have guaranteed delivery with retries until the CRC check passes. This means there are no guarantees regarding bandwidth or latency, making it unsuitable for many audio applications.

We are still talking about edge case IMO and not the standard use case.

Everything from purpose built streamers to something like my Pi4 endpoints are purpose use. If there is no retransmission then the result won't be subtle.

I find the argument of "Audio data is considered non-critical, so bit perfect transmission is not guaranteed." disingenuous because we can easily follow the best practice of single purposing our non-realtime playback systems. While technically correct, it's not even remotely, consistently encountered.

I'll also consider myself corrected on the underpinnings. But gotta be honest with you: I don't have an audio playback system with 12 USB ports and all sorts of peripherals hanging off of it. My endpoints only USB connection is the DAC and the Ethernet hangs off a different bus.

 

[Jinjuku]

I'm referring to USB audio data type packets.

My apologies btw and it's my misunderstanding.