USB Cable

@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.

@tvrgeek interesting discussion of how the USB interface could become noisy and why.  Seems from your discussion that you lay more blame for any differences in performance on deficiencies in equipment design rather than the cables.  I am wondering if you've done any listening tests yourself to see if you hear a difference in different USB cables in application with different gear and in different settings/electrical environments?  Have you, for example, done listening tests comparing a "premium" USB cable with an off the shelf Belden and/or generic Chinese USB cable in different settings?  If so, what did you learn?

It seems to me that you focused most of your discussion on the relationship between digital cables and the immediate gear they connect.  But things can get very complicated in actual user set ups, often with multiple pieces of gear and their cabling creating multiple electrical fields in the neighborhood of your computer/streamer and DAC, not to mention all the other electronic devices operating in your vicinity.  This along with variables like the different physical proximity of devices to one another and differing levels of power conditioning and noise suppression in different set-ups would seem to make empirical testing of different cables in different applications a must.

Your mileage in terms of performance and what helps or degrades performance of digital front ends in the context of cabling may in fact really vary, and it may be in part dependent on factors that are beyond the relationship or designs of the sending and receiving devices in a single USB connection.

kn

It is the complex environment of what you speak. This is why USB and Ethernet cables are twisted pairs and shielded.  The designers knew this. Partly for the spec of 11 feet. USB was not intended to exist in a vacuum. 

Yes, I blame shortcomings on the end points not implementing good practice.  In a $100 DAC, it is cost driven so some slack is given. But in a $500? Nope. $5,000?  Pure incompetence. 

I did loopback tests between free cables and correctly designed USB cables.  Big difference and it shows up in a spectrum analyzer. Added an isolator, and presto, no problem.  Two piles, good and bad. You can add a braided sheath and a fancy box, but it won't transfer bits any better. 

Remember, it is not the digital waveform that matters. It is how it is detected, PE, NRZ,  windowed, etc and then gated into a shift register to be accessed by the DSP section. Even DSD is re-generated.  No place for magical properties to hide. 

FWIW, I just ordered a D400es and it does NOT have a galvanic isolator.  Bad design for that price point considering how much they spent on the cabinet. I will test  both with an analyzer and my ears if ones needed in my cabinet.  I pay attention to cable dress  and common power so It probably is not. I have dead silence through my speakers with no active signal.