Difference in sound between copper and silver digital cables?

Williewonka, the TCP/IP stack is software not hardware.

I used to be CCNA certified (never renewed because it costs money for nothing and I don't work in ICT anymore).
I am not very good at this but I will try to explain the important things (related to this topic).

Ethernet is made out of layers (check OSI model) and only the first layers are hardware layers.

The first layer is the physical layer (interface port and the copper).

The second is the data link (ethernet frames are created and use of a mac address, it's the last hardware layer) while this layer has CRC it will NEVER resend a package, lost is lost. The server interface stats I linked come from this layer. Typical layer 2 devices are ethernet switches.

Starting at layer 3 it's all software. It's here that TCP/IP packages are created and eventually resend. If you would look at the TCP/IP statistics you will see that packages are dropped, blocked, ... etc. This doesn't mean there was a error in the hardware communication, if it reaches this layer "there were no errors on the cable" but packages were dropped/blocked for a different reason (unexpected or unwanted packages)

I am not 100% sure about netstat in Windows but if I am not mistaken "netstat -e" shows the hardware stats and "netstat -s" the TCP/IP part.
There you can see that the first one has no errors (unless you are on wifi, have a bad cable or interface) while the second one has errors, dropped packages ... etc (again those are non physical reasons).

Yes I lied (partly) because I didn't want to explain the whole thing in depth. Layer 2 has a CRC but It never resends like what most ppl here would expect from a system using a checksum. But in 27 days, my server never had a bad ethernet frame (every '0' and '1' has arrived correctly to the next node, the switch, and not single CRC trip).

PS : ethernet is asynchronous there is no clock signal between nodes.

@danip5 - you are clearly far more knowledgeable in this area than myself, so if I could impose on you one last time, for some points of clarification...

If I understand your posts correctly -
"Ethernet" detects errors, but it does not request a re-transmit - it just identifies if the packet should be "dropped/blocked"

Whereas TCP/IP "can" notice the data loss, but...
- is retransmission something that is "programmed" using TCP/IP ?
- or is retransmission automatically taken care of by TCP/IP ?

The reason for this point of clarification is
- if re-transmission has to be programmed - then it really depends on the TCP/IP implementation approach, from one Ethernet connected device to another, as to how good each would sound.
- Whereas, if it is automatic, then all Ethernet connected devices should be able to perform to a "similar level".

Also - Is my understanding of SPDIF, optical and USB methods of transmission correct...
- i.e. if data is lost/corrupted, it goes undetected and a DAC will simply try to re-create the audio signal from the digital stream received as best it can ?

It is also quite clear from your posts that Ethernet is far more reliable at successful data transmission than either SPDIF, optical and USB methods. Which would account for the superior sound I now enjoy from my Bluesound Node 2 - which uses an Ethernet connection

Many Thanks for your patience - Steve

Guys,

I don't know all of the technical and configuration aspects but I have evaluated 7-8 digital coax utilizing both RCA and BNC; I was able to distinguish differences in all of them easily.

It must be the 3:1 ratio of the helix coil/signal cable that's making a difference. There is No brightness, bloat but an enveloping sound that appears to have nothing obstructing the components ability to convey the data being transmitted.

I will be removing from cooker tonight and placing on soundbar for a few days and see what a DIY Helix sounds like compared to a professionally built German Helix Cable.

I can tell you that I'm quite impressed already with this DIY Helix 👍

Wig

Williewonka, to keep it very simple.

The network interface sends ethernet frames which are composed of a header, a payload and a CRC. At this stage it uses mac adresses to communicate.

A TCP/IP packet is a software created packet which will be the payload of a ethernet frame. TCP/IP is a little more complicated to explain but it uses a 3 way handshake to start a connection. Sequence numbers are used in those packets so that the a missing packet can be detected (if sequence number unexpectedly increases) and a resend can be asked with it's sequence number. For example if a package with sequence number 65 is received while there was no 64, a resend of 64 will be asked (it will actually go back to 64 which means that 65 will also be resend ... etc)

If you send a TCP/IP packet that packet will stay the same until it reaches it's goal (rare cases where it doesn't like a router using NAT), while every node will "repack" the TCP/IP packet into a new frame with the according mac addresses (a switch is not a node).
When a TCP/IP packet is lost it almost certainly happened "far away" (for example due to lack of bandwidth)

To get back on topic. I think the major problem with SPDIF is that each device generates it's own clock and older devices often generated a crappy clock.
Today's devices generate more consistant and accurate clocks which means less jitter problems.

@danip - all good :-) 

Many thanks for taking the time to explain.

Regards  - Steve