USB Cable

@hce1 

Nice post.

A really crappy, like the free ones can, and I have measured them, introduce measurable noise in a system. Audible or not is subjective. BUT, a well designed client USB receiver is immune to that kind of problem.  If you are running USB mode 1 then varying cable parameters in off-spec crap cables may cause jitter issues as you are using the source clock.  Run USB mode 2 asynchronous, and no more problem.  Data is buffered and ALL timing is in the client side. 

A lot of even expensive boutique DACs have crap USB receivers, so a "correct to spec" USB cable may well improve the sound.  Band-aid for an old  client.  Boutique companies do not always have the time and budget to stay up on fast moving technology. Some of the USB issues were not well understood 10 years ago. 

A USB-1 spec cable should be more than enough bandwidth for audio, but most cables meet at least level 2 spec. If USB-c on BOTH ends, it will need to meet the level 3 spec for reliable data rate.   Look them up.  A to C who knows. 

 If you have a DAC without galvanic isolation and you believe some garbage is getting in, you can get a perfectly good AMD Galvanic isolator board from Amazon or E-bay for $12. You can get the same transformer in a boutique box for $400 and every price in between. No ground loops. No source ground or power noise injected into the client. 

An exception is if the client is powered from the host USB.  In some cables the 5 and gd are not shielded so noise pickup is possible but probably trivial compared to the crap a PC puts on the line. Isolators are designed so you can inject high quality power on the client side. Again problem solved with science.  I do not know all cables, but Belden stock is two pairs shielded with an overall.  Monoprice may not be. China Inc?  Your guess is as good as mine. 

The USB interface is well defined and respectable companies like Belden make cable certified to the spec. I keep mentioning them because I know them. That does not exclude the hundreds of other raw cable manufacturers.   No magic needed.

Using asynchronous mode,  It can't effect timing, resolution, space, air, attack, presence, blackness, or any of the "your system is not resolving enough" excuses.  Against the laws of physics.  

You can pick up and inject noise over the 5th connection. The outer shield. Again, a well designed receiver will reject this, but so will a 49 cent ferrite on the cable. 

There is a maximum spec on USB cable length but not a minimum. Some have suggested ring-back on a short cable can cause jitter of the bits.  The physics are correct and you can measure this, but it has not been shown that a correctly designed receiver has any issue with bit to bit accuracy into the buffer. 

So, to "deniers"  there are situations where it can or could have caused a problem.  To "believers" you may be hearing the difference between crap and correct, may be hearing a band-aid for a different problem, or may be hearing because your brain said if you spend more it has to be better.   Whatever makes you happy.  If that multi-color braid over Chinese bulk cable for $400 makes you happy, go for it.  Maybe they were nice enough to use 8723 as their stock so you do get a good cable. 

FWIW, a steamer is just a smaller PC with fewer applications running. Maybe it has a cleaner power supply, and maybe a cleaner USB port.    If you are using the PCM ports, then better hope it has a much better clock, but I notice the newer DACS are also buffering and relocking PCM so even that becomes moot.   Or is that mute :) Go streamer because you want the user interface which is configured for media. Not for magic.  I use a PC because I am old and don't have a phone attached.  I also like being able to adjust the OS and player parameters where in a streamer, they make it easier by doing that for you. Hopefully the best choices. Some of these parameters can make a big sonic difference. Bits are bits but what you do with them matters. 

Summary. Using USB mode 2, it's nothing but a transport to move bits from one memory buffer to another. There are ways to mess that up. Engineering helps. magic and money don't. The spec is reliable. 

@carlsbad2 Current high end streaming is supposed to be TCP from discussion on A’gon. I have no time to Google this to show proof. In the past I believe music streaming was UDP.

I have ChatGPT open and asked it the question.

 

Music streaming services typically use a combination of protocols for delivering audio content to users, and TCP (Transmission Control Protocol) is one of them. However, it’s important to understand that the architecture of music streaming services can involve multiple layers of communication, and TCP may not be the only protocol in use. Here’s how it generally works:

1. HTTP(S) for Control and Metadata: Music streaming services often use HTTP or HTTPS (secure HTTP) for transmitting control commands, metadata (track information, album art, etc.), and user interactions. These protocols are based on TCP.

2. Media Streaming Protocols for Audio: The actual audio content is usually streamed using specialized protocols designed for efficient media delivery. While TCP can be used for this purpose, some music streaming services may use UDP (User Datagram Protocol) instead. UDP is preferred for real-time multimedia applications because it provides lower latency and faster data transfer, which is crucial for a smooth audio playback experience.

   • HTTP Live Streaming (HLS): HLS is a popular streaming protocol used by services like Apple Music. It segments audio files into small chunks and serves them over HTTP(S).

   • Dynamic Adaptive Streaming over HTTP (DASH): DASH is another HTTP-based streaming protocol used by some music services. Like HLS, it segments content into chunks and adapts the quality based on network conditions.

   • UDP-Based Protocols: Some music streaming services use UDP-based protocols for live streaming, which can provide even lower latency than HTTP-based protocols. These may include RTP (Real-Time Transport Protocol) and WebRTC (Web Real-Time Communication).

In summary, music streaming services use a combination of TCP, HTTP(S), and potentially UDP-based protocols for delivering audio content. While control and metadata often rely on TCP, the actual audio streaming may use protocols designed for efficient real-time multimedia delivery, which can include both TCP and UDP, depending on the service and its specific requirements. The choice of protocol may also depend on factors like network conditions, device capabilities, and the streaming service’s architecture.

Well if you read it on Audiogon and confirmed it with ChatGPT, it must be true.

Well I have not confirmed anything, I just posted some data that seems to support what I am saying. You were making a definite claim that streaming is lossy (and thus  UDP), such as watching a live sporting event on streaming video.

I used to think that way too for music but I have started to think that streaming music (at least Qobuz and Tidal level) are TCP based, and thus guarantied delivery.

Anyways, I got to get back to work.