(I hate doing this but: 15 years professional linux system administration and five years hobbiest of the same before that)

I'm strongly in the "can, shouldn't" camp. Theoretically if your cable is so bad that the two computers have to re-transmit the data so often that you get a buffer underrun then yes, it'll have an impact. But assuming you are using a cable that can reliably handle the demands of basic home networking there should be literally zero impact on the end product. So the short of it is: don't use super garbage cables, don't have insanely long runs of unshielded cable (20+ meters), and don't do something stupid like wrap them around house power.

If you're not interested in technical commentary about TCP/IP and why high-cost ethernet doesn't make any sense, stop here.

Still here? Cool, lets rock! I'm probably going to end up being terminology heavy and definition light, so feel free to ask for clarification.

While the author is correct that the transport medium (the cable) caries a pulse-modulated analog signal, the timing and error correction data built into each packet at the protocol level means that a busted packet will be dropped and resent. In essence, there are only two possibilities: the packet arrives unmolested, the packet is thrown out and retransmitted. Both of these events are entirely transparent to an end-user application which sees an unbroken stream of data. Again, and this is super important, IP is a datagram-based protocol which sends data in discrete chunks, TCP is a connection protocol sitting on top of IP doing quality control and managing successful delivery, and your operating system handles pulling the data out of the packets and reassembling them into a correctly ordered stream. Because of this layering, your application sees a continuous stream of data that by definition must look identical to the equivalent bytesteam generated and consumed locally.

Before we go any further I have a brief aside: all of this only applies to TCP/IP based transmissions. If you use a protocol like UDP (also over IP) or IGMP (another internet layer protocol like IP) you do not get any retransmission guarantees, ordered reassembly guarantees, or any of that. Generally speaking though, point-to-point transmissions (like streaming music from your media server to your playback computer) don't need the speed benefits of UDP, and don't need the multicast functionality of IGMP. As an aside to the aside, the reason internet TV occasionally has graphics glitches is because internet TV uses IGMP as a transport and if a busted packet arrives there's nothing the protocol can do.

So now that we've established that TCP provides delivery guarantees (regardless of the quality of the physical link that it is going over) it should be obvious that a packet switched TCP network (a category that includes every home network) is incapable of having data breakage in a way that degrades playback quality. This isn't to say that it can't have data breakage that makes things impossible to listen to, but that would be because the underlying network was hostile to all forms of data transfer, most likely making the connection unusable. So, bringing things back around to the beginning, as long as your cable runs are good enough to push the bandwidth needed to copy the data stream faster than your playback (roughly 1 MB/s for 192 khz 24 bit uncompressed audio, basically the peak of what anyone should be shoving across the wire) plus whatever other networking demands you have there will be zero difference between $1/foot and $100/foot cables as the
protocol literally makes that impossible.

Questions? Comments?

EDIT: one note here, I'm talking about home networking situations where your media lives on one computer, your playback system is on another, and you're streaming either the file or the decoded PCM data across the wire (or DSD I guess, for the six of you with DSD media collections). I am not talking about anything using a multicast or UDP based broadcast system like internet radio does. Mostly because anything without delivery guarantees going across the internet is guaranteed to suck, and no amount of good-vs-amazing cable will make up for that (remember, TCP/IP was designed around delivery guarantees in unreliable environments).

EDIT THE SECOND: Doing an objective test is easy: copy a file across your network from your file server to your playback system and then run a file hasher on them both (for mac/linux/bsd systems I suggest the command line sha1/sha1sum, for windows I'm sure you can find something) - the hashes should be identical. The subjective test is basically the same: play back the file over the network, then play back the file from the local copy - they should sound identical. If they hash to different values your network sucks, if they sound different but hash the same you're most likely imagining things as the files are essentially identical. (Yes I'm somewhat taking the piss here, but the whole thing is silly to folks with a compsci background)

The reason it bothers me so much is that you don't even need double blind tests to do it. You can literally do a byte-for-byte comparison of the data coming off the wire against the same data locally and know if you're getting the same results. Plus, the failure modes for any kind of digital transport are real obvious (dropouts, blips, etc) since it's a serialized bytestream as opposed to the whole spectrum of degradation that analog signals can have. It is true that some folks won't trust it unless you do a blind test, but transmitting across the wire into a digital frequency analyzer really should be all it takes.

Generally speaking, the gold standard should be anything that can reliably transfer data at 100 Mbit or better, which means most short runs of cat5, and any run of cat6 or better where the wires aren't actively damaged. If it's good enough for home networking, it's good enough for any variety of data transfer: encoded audio, video, or whatever.

This is a great post.
I have to say I couldn’t claim to be able to explain this to anyone, but it makes sense to me. It is an interesting discussion and there are some good sides brought to the table here and for me personally, I’m thinking my (modified somehow by Andrew at LGC) cable is doing its job because when I upgraded the next one, my USB upgrade it made a significant difference.
 Thanks for posting, hoping to see more on this subject.
Best,
Scott

It's after 2am and I need to be up in a few hours, so I'll keep this brief.

I agree with you Colin, when we're talking TCP/IP the data is going to get there, and get there accurately...otherwise the stockmarket would be a mess, right? That said, doing a hash comparison only proves the data got from sending computer to receiving computer - I'm not listening to packets, nor am I listening to my computer, I'm listening to my DAC. So what we need to look at and evaluate is what happens once those packets are hitting the 99 cent made in China network chip, what happens when it hands that data off to the DAC, and if a network cable can have any effect on this what so ever.

Back in the day everyone was saying  USB cables can't possibly make a difference! My printer doesn't care if it's 99 cent cable or $400 audiophool cable...You're all delusional!! But then once people started looking at how the streaming audio formats work, how the bits are transmitted, how the bits have *timing* attached and how a cable can skew all of that and actually indeed change the sound...well then, we will just move the goal posts and it's all placebo because you can't possibly hear that!!

What I'm getting at is that if people are hearing a difference in Network cables, and we *know* that it can't be lost data due to how TCP/IP works, then we are possibly missing something, or too focused on the wrong something(s); just like we were with USB before that. Let's stop hashing the same hash about checking file hashes (sorry, I couldn't resist LOL), because that hyper focusing on the fact that the network gets the data from point A to point B perfectly is just a distraction from looking at what *could* affect sound.

Just to be clear, I agree 100% that the network gets the data there 100% reliably. If there is a sound difference, it's something else. Also, audio streaming via USB, TOSLINK, Coax, is completely different and has been objectively and subjectively proven that cables can make a difference.

Man I hope that made sense, it's 2:40am and I'm not confident I'm coherent. LOL

Thanks for the info Stan.  I was planning on purchasing the UltraRendu in the near future, but will wait to see what the reviews are on the new optical player first.

Sounds like you are diving into the digital ocean, Geno.  Cool!  The micro- and ultraRendu both deliver excellent sound quality and I expect the optical- to sound a little better even.  

Contrary to my earlier comments about all the players/streamers that I had used reading from attached drives, the -Rendu devices only receive files via ethernet (optical or copper).  Just wanted to clarify.

The USB port on them are their outputs and there is no option for internal storage so I don't think of them as players exactly though I guess they essentially are.  They require third-party software to function, though several options are built-in or pre-installed. Plus they require a server of some kind to stream files to them, either your own files or over the web. Not difficult if you have a wired network in place, especially if you are planning to use Roon.  A little trickier to go wireless and open-source (free), but I did it (now I am running all wired and Roon as that is arguably better sound-wise).

I wish I had this forum as a resource when I was spending hours of trial and error to figure some of this stuff out.  Still learning, call it a fun adventure!

I don't think I have thirty years left in me!

So my second "Optical Starter Kit" from Small Green Computer arrived and so did 15m of optical cable from SF Cable. I put the two switches next to each other, left most of the cable coiled, and simulated my intended interim setup without moving anything else or fishing any cable behind the couch or to the other side of the room. Plug and play!

My first impression was it's not quite as stunning a difference as was swapping in the better switch with linear power supply (see my earlier post), but 50 feet of optical ethernet is maybe a skosh quieter in the quiet places than the original 30 feet of copper alone.  Blacker blacks as they say in the hifi magazines. Could be placebo effect.

The 30 feet of copper is still there between the server and the first switch (will change to 3 feet when all done), then the experimental 50 feet of optical, a second identical switch, and finally about .5 meters of AudioQuest Cinnamon ethernet before the ultraRendu. As I listen a coupla hours now, my impression (placebo or not) is expanding to, 'it just sounds better'.

Here is a discussion from a couple years ago about streaming that might be interesting:

https://www.decware.com/cgi-bin/yabb22/YaBB.pl?num=1633788897

I have a different take on how networks impact digital music than Colin B.