Wifi vs hardwired for streaming

So, NONE of the network upgrades sold to audiophiles -the audio grade routers/switches blah blah expensive cables blah blah matter one tiny "bit".

But I will disagree, as some of those audiophile network devices clean up the noise just before that first audio device, and better than the audio device can do itself. I personally have used the Stack Smoothlan and now the Regenerator before my Antipodes server, there is no doubt that it is an improvement.

So some of the audiophile network gear is a waste, but some can be effective, in the right place.

Let’s keep it simple:

1. Maintain good separation between your audio gear and the router (or Wi-Fi extender) — at least 6 ft. Use a well-shielded Ethernet cable. At short cable lengths, you don’t need to worry about the cable acting like an antenna coupling noise.

2. If the distance is long (around 20–30 ft or beyond), use a fiber-Ethernet setup with good-quality FMCs, SFPs, and a linear power supply (LPS).

3. Disable Wi-Fi on the streamer if it doesn’t automatically turn off when a wired connection is used.

For short distances, there’s really no need to bother with fiber-Ethernet, even though it’s now very affordable. Again, for short runs, use a well-shielded Cat-8 cable instead of the unshielded Cat-6 that many people rave about.  At these lengths, antenna effects from a shielded cable are negligible, but blocking EFI/RF noise from entering the cable and streamer is paramount.

I need to address one additional point that is really separate from my earlier posts about "noise"... The PROTOCOLS used for audio streaming are different for different services.  

TCP-based protocols are error detecting and error correcting or require retransmission for corrupted data.  They are designed for reliable and exact content delivery.  The only concerns the audiophile has is providing a decent network on your side of the pop router from your ISP --and-- avoiding injecting noise on the last leg into your device (per earlier posts)

UDP-based protocols are NOT.  The concern for the audiophile is the same as for TCP but now your entire path from the streaming service all the way Ito your audio device is subject to lost data or corrupted data.  Think about this: what percent of that distance is under YOUR control???

@akg_ca I enjoy his channel, but he clearly is in a steep curve learning process between the first of his videos on this topic and the most recent one.

What audiophiles "hear" when they make changes is due to multiple interacting factors, and "debugging" for better audio quality is going to be more random than informed if you do not bother to understand the two realms: digital and analog voltages that convey the digital data.

The one wrinkle is how different streaming services implement their transmission. The basic question is do they use reliable error detecting/error correcting TCP-based protocols or do they use faster and less reliable and error allowing UDP-based protocols?

If the answer is UDP -- the little you do on your side of the ISPs router is but a fraction of the distance the data traveled... good luck fighting reality in that case! That service was designed to be spotty.

This post offers another approach.