Skip to main content
Topic: What does a bad USB cable sound like? (Read 1177 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What does a bad USB cable sound like?

What kind of noise or distortion does a marginal USB cable make?
I don't think that any of the common audiophile descriptions fit.
Kevin Graf :: aka Speedskater

Re: What does a bad USB cable sound like?

Reply #1
Usually a bad USB cable will cause the device to disappear and reappear in windows periodically.  You'll have audio and then sudden you won't when a transfer gets corrupted and Windows resets the device. 

Re: What does a bad USB cable sound like?

Reply #2
What kind of noise or distortion does a marginal USB cable make?
None whatsoever.

I don't think that any of the common audiophile descriptions fit.

'course not. Audiophools, not audiophiles, make it look like it behaves as some sort of analogic media, when it is obviously does not.

Being digital, all those zeros and ones will either get to the other side or not, or, in more realistic terms and as Saratoga's pointed out, the device will be recogzined or not. So no "noise" is supposed to be generated from that.

Listen to the music, not the media.

Re: What does a bad USB cable sound like?

Reply #3
USB is a differential transmission line. Meaning the the data is sent on both the D+ and D- wires at the same time. On the receiving side, the D- line is inverted, then summed with D+ and that's the signal that's being decoded.

Since USB is digital, it's best to think of it in terms of data.

USB cables have two common failure modes:
 1. they cannot carry enough current on the Vcc and GND lines (this is often plainly obvious with phones being charged very slowly, etc).
 2. Improper shielding and/or improper twisting of D+ and D-. Both of which introduce noise into the signal and hence may or may not corrupt data, in the sense that the differential signal is not decodable.

Should failure mode 1 occur: when your playback device is powered by USB, then it simply won't work, because there's not enough power going to your player, or amp, or whatever.

Should failure mode 2 occur: if the data is undecodable since the levels aren't discernable, the host (USB is always host controlled) will probe the USB device a couple times, and if that doesn't succeed, the device will be rejected.
Host controllers must cut power to the device should the enumerator be unable to probe the device. If you plug in something like a mouse into a USB port very slowly, you'll see the mouse LED or laser switch on, then off, then on again. This is because while inserting the mouse your connection is intermittent. The host controller then cuts power. The controller will then usually give the device another chance to see if the connection has been settled down, this is usually with a 1sec delay, to allow for someone to actually plug a device in, as USB is hot-pluggable by design.
Should this fail a couple more times (usually 12 times for some reason), the host will permanently cut power, and only retry after it sense that the device has been unplugged, and re-plugged. The controller now assumes that another device has been plugged in.
Up to this point, the device hasn't even been attached to the bus by the enumerator.

USB is a logically enumerated device bus, even though it says "bus" in the name, the bus is a logical bus, not a physical one, like with SCSI, for instance. All devices are connected directly to the host controller, and only the controller may initiate data transfers (hence, host controlled). Enumerated means, that the devices are only ever attached to the (logical) bus, when the host controller is able to attach the device at the enumerator. I.e. you can't send data via USB "in the blind" like on an RS-232 line. When the host controller is unable to poll the device on the other end, even though "something" is plugged in, it won't show up to the enumerator, meaning it doesn't exist on the bus.

Before data is being send to the attached device by the host, a set of commands are sent by the host controller. The device on the other end must either accept or reject packets based on their CRC checksums. the ACK or NAK replies are then sent back to the host, the host might want to re-transmit that packet.

If you're using an un-shielded, untwisted USB cable, it will basically require frequent re-transmissions, assuming the noise is not high enough to completely make the signal illegible to the controller. For instance, you're running the bare D+ and D- wires of the USB cable next to a switchmode power supply, and it just induces the right high-enough levels for a host controller to incorrectly assume they're data. In this edge-case the USB connection will seem to be very slow. In this case USB behaves much like Twisted-Pair network cables, as should be evident.

Now, what if that data is PCM audio? Well, if the host controller cuts power and detaches the device from the enumerator, you'll hear nothing, as the device is essentially removed from the host - as saratoga noted correctly.
If communication over said USB line necessitates frequent retransmissions, the USB connection will seem to be slow. So either the sound will be choppy, like streaming from a very slow source, like on very slow internet, or it will buffer forever. Usually, timeouts on USB are rather short, though. So even though the USB will work on the enumerator side, it will give up after a couple tries, and simply let the devices on either end handle error notification, etc.

On controlled digital lines, whether it's USB, or twisted pair networking or what have you, introducing noise into the signal transmission simply means the line gets slower. Down to the point where zero packets reach the other end before either side gives up requesting re-transmissions or re-transmitting itself.

Long story short: What does a bad USB cable sound like? The same a slow or choppy internet connection sounds like.

Incorrect data is always rejected, never simply forwarded no matter what, similar to packets over TCP/IP networks. You either receive the packet, or the NIC rejects it. Same with USB, the host or the slave either accept the packet when it passes its CRC, or reject it. And if the host gathers too many such errors, it might simply decide to remove the device from the bus when control commands are rejected, too.

SimplePortal 1.0.0 RC1 © 2008-2018