Do I need an expensive digital cable?


I have been using a fairly inexpensive optical cable to connect my CD transport to my Moon 280D streamer. I was told that an SPDIFcoax cable would sound better. For an experiment I purchased an inexpensive Pangea coax cable. It didn't sound at all because its terminator ends did not fit snugly in my equipment. I consulted chatgbt who often gives me audio advice. It advised that for the short run of 1 meter, an RCA interconnect would work. It did. And sounded much better than the optical. Chatgbt said that RCA interconnect was good enough.

Now, there is a twist to this story that might make those doubters think twice. A digital cable carries packets of information that are rechecked to assure that the streamer is recieving correct information. There is the timing concern, though. But my Moon 280D has an asynchronous DAC with a clock as part of the DAC. Any information sent by my transport, whether it is clocked by the transport or not, will go through the Moon's asynchronous DAC's clock. So ;there shouldn't be a timing problem. Should there?

Can anyone make a case that I should buy a "better" coax cable?

audio-b-dog

@audio-b-dog 

Networking was one of them. I think that networking is done in packets

Spot on for computer networks, where it is critical that data is precisely the same when received as when sent. To achieve this, additional data is included in each packet so that errors can be detected, and either corrected or the packet is re-transmitted, multiple times if need be.

If packets have to be re-transmitted, there is an obvious timing problem!

When data networks started to be used to transmit sound, initially for telephone conversations, timing became critical and, as the pharmacist advert claimed, we dispensed with accuracy.  Entire packets could be dropped, usually without throwing away the gist of the conversation if enough timing was preserved.  The technique of discarding packets was called streaming, which aimed for a fairly steady stream of packets, even if some had to be dropped.

Suddenly all the arguments about "bits are bits and are always perfect" vanish, just like the bits that have been dropped.

Now we have to delve a bit deeper, to see which parts of our networks actually stream, and which parts implement full error detection and recovery.  It does not help that the main network protocol in use today, Internet Protocol (IP), is designed to connect a network of different networks.

Indeed, as its fundamental level, IP uses two different protocols, one called Transmission Control Protocol usually written as TCP/IP, and one called User Datagram Protocol or UDP/IP.  By now it should be no surprise that TCP guarantees data integrity but not timing, while UDP prioritises timing at the expense of data integrity.  Which would you choose for streaming?

Surprisingly, some streaming service providers like Qobuz do choose to use TCP but then you have to ask "at which point is TCP handed off to a different technology that does not perform error detection and recovery".

Sometimes the answer is easy.  For example, I2S does not perform any error detection, let alone recovery.  It was only designed to allow two chips on a board to pass 16-bit PCM.  So you can't complain if you hear audible differences if I2S is anywhere in your chain.  I2S bits ain't perfect.

What about Universal Serial Bus (USB)?  USB manages to transfer data perfectly between disks and memory, after all.  But wait, USB also has a streaming mode which - you know the story.

Ethernet then?  Same deal.  Can be made reliable if TCP/IP (or some similar higher-level protocol) is used end-to-end with Ethernet in the middle.  But then you cannot guarantee timing.

The above ignore secondary effects like Electro-Magnetic Interference (EMI) interacting with your sensitive electronics.

Hope this helps

@audio-b-dog understood. Thank you for that information!

you used chatgpt you said in your original post. 
use chatgpt to get answers on these questions 

1. what is bit depth in audio

and

2. With cd transport connected to dac via coax cable, which unit is the master clock

 

a digital signal is still analog voltage passing through the physical wire, in rounded off square wave shapes

True.

... so a poor cable exaggerates transmission error to the receiving device.

No, it does not.

Unlike an analog signal, a digital waveform merely indicates whether a bit is on or off (1 or 0). Any voltage (amplitude) above a predetermined threshold means a 1. Any voltage below another predetermined threshold means a 0. As long as these thresholds are met, the bit will be set correctly and it does not matter how clean or how awful the analog representation of the waveform might look.

Now, some cables might pick up EMI and RFI along the way, which might adversely affect sound quality if any of the connected components are poorly designed and / or built, but that is completely independent of the digital data transmission per se.

@audio-b-dog  With a USB connection into your Moon 280D, the data stream is asynchronous (untimed) until it reaches the DAC’s internal clock. With Toslink/coax/AES EBU/I2S, the source device (e.g. your CD player) holds the master clock, and the data transmitted to the DAC is synchronous (timed). Clock quality is most certainly a factor in the overall result, and another variable to consider as to why one type of connection to a DAC can bring a different result than another. 

The proper characteristic impedance for both coax cable and connectors is 75 ohms. Audio RCA connectors are typically 20-50 ohms, so a better coax cable will use connectors of the correct impedance. Proper impedance minimizes unwanted reflections. Where one is flexible about cable length, 1.5m (~5ft)  coax cable length has been demonstrated as theoretically "ideal" for reflection mitigation. Splitting hairs possibly, but worth a mention. 

@richardbrand you do have to remember though that streamers buffer the incoming data stream in memory. TCP is a clock-less protocol: by design it does not have nor need a physical clock, unlike USB etc. which do.