It looks like the big spend (besides avoiding Gigabit being a feature… wow) is the power supply being linear. Having taken scopes to power lines in homes, I can grudgingly attest to the non-zero impact switching power supplies have in audible frequencies.

But it’s comically small and solvable much more easily than spending this kind of coin.

I was expecting an AVB switch with locking connectors and redundant power. You know, like a pro audio mission-critical device. Instead it’s basically like using stacks of hundreds to vibration insulate your CD player. It might technically improve things, but the return on investment is poor.

> having taken scopes to power lines in homes, I can grudgingly attest to the non-zero impact switching power supplies have in audible frequencies

I haven't used a scope, but I have had some laughs plugging things into the same circuit as high gain guitar equipment.

Yes please, let's amplify those audible frequencies to audible levels. A good PSU goes a long way.

By the way, if you are ever tempted to measure AC with an oscilloscope, please use differential probes to reduce the risk of damage/electrocution. It is very easy to create a pretty significant voltage potential across your probe and reference when poking around with high voltage.

The thing is, there's this plausibility factor that makes it hard to filter out BS

You could 100% design a network switch to be good for audio.

- ensure periodic packets like say arp don't introduce jitter

- do qos on audio streams vs other data

- favor latency over throughput

- maybe tune things like MSS to keep packet sizes smaller, but no fragmentation

etc..

Yeah, no because "streaming" is just transferring a chunks that can then be played. You are not sending bits from the network card straight to the audio out. Even if you have a certain % packet loss, there is 0 impact on the playback as long as the next chunk arrives before the previous one has finished.

You know, streaming isn't really just getting bits across the wire intact.

For one thing, timing is important. A simple example would be getting video in sync with audio. You could go deeper and manage timing for speakers side to side or front to back. It would get lots harder if a microphone was introduced - then latency would be a big big deal.

These sorts of things are probably why bluetooth isn't used as much with a/v systems.

(lol, here I am arguing the merits of an audiophile network switch)

> For one thing, timing is important.

So long as the amount of audio sent in a packet is larger than how long it takes the next packet to get there, you'll be transfering audio data faster than it is playing, making minor fluctuations in timing between packets irrelevant.

Bluetooth isn't used because BT audio transmission is lossy, audio gets recompressed. Newer BT standards have good quality compression, but you are still recompressing the audio. BT isn't meant to be a high bandwidth protocol.

BT's latency around audio is because 99% of BT implementations suck. Latency can be as low as 50ms or so, but it is often in the 100s or even 200s of ms.

> So long as the amount of audio sent in a packet is larger than how long it takes the next packet to get there, you'll be transfering audio data faster than it is playing, making minor fluctuations in timing between packets irrelevant.

Even major fluctuations. Not talking about the quality here (but the received quality is identical to what is being sent), but just think about Netflix & Co, Imagine if they had to maintain an "ideal network, with no packet loss and constant ping" to your device or otherwise audio and video would be out of sync?

There are protocols that shuffle more or less raw audio streams over the network (Dante for example). In that case yes, you do things to make sure the variables are within a certain range by (usually) segregating the traffic etc, but even then if the timing is off the playback will stop until the stream is reestablished properly. Theoretically it's the same as with any other media stream, just much more sensitive to fluctuations as it is real time (i.e. delay so low you are unable to hear it).

192khz/32bit audio track is 6.144Mbps. Assuming smallest data packet, at 64 bytes data per packet that's 12kpps. Any switch that has more bandwidth per port, more total non-blocking switching and forwarding rate that the sum of each port in use will suffice. These days, you would definitely go for gigabit non-blocking switches which have <1ns inter-packet gap and way too much bandwidth and forwarding rate than what your PCM stream needs.

If you're talking about a general WAN, there's no guarantee that jitter on your route may not violate 12kpps, and it's quite common on most oversubscribed ISPs to stutter receiving 6.144Mbps due to occasional high latency causing a missed packet window (oversimplifying here because there are audio receive buffers as well.) Over a LAN this would only happen if you're pushing your switch to the limit.

Should you buy an audiophile network switch? God no.

But this only matters either if you don't have enough bandwidth to compensate and a buffer, or for whatever reason can't buffer much (e.g. it's live and two-way)

Yeah hence I mention the WAN. Generally some link along your WAN route is oversaturated, on a shitty ISP it's probably the link to your local ISP itself. I presumed audiophile switches would be popular for real-time streaming solutions, but I still don't understand the appeal.

> 192khz

Please don't. You'll make Nyquist sad. https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

On its way to your speakers, a audio file sampled at 192khz will ideally be identical to a recording done at 44.1khz, except over sampling can introduce audio artifacts that degrade audio quality so you can end up with worse audio.

So, please, don't unnecessarily over sample.

I can encode video in real time and send it a hundred kilometers with lower latency than Bluetooth can send 192kbps of data to my ear.

The larger the buffer size, the larger the latency. This is mostly irrelevant for playing an audio file, but in some cases a long chain of buffers in the OS before it leaves to the speaker can be an issue for music.

The main place you will see this issue is playing audio in something like a video game due to an action like pressing a button, firing a weapon, etc then it can be very noticeable if you're buffering too much audio because it wont sync to what you're seeing and the game will feel laggy even if it's running at a high frame rate.

The timing is determined by the sample clock of the DAC. The network switch has zero influence on it. If the system has multiple DACs and/or ADCs, their clocks can usually be synchronized via BNC cables.

What if you have multiple dacs (and other types of conversions)?

Excepting subs, it seems many speaker systems are hardwired together downstream from the dac, but there should be a good way to have multiple independent speakers networked together that could be time consistent. and audio <-> video consistent with whatever display you have.

and bnc cables.... would be another whole network.

Sorry but you keep talking about timing. With network speeds nowadays, the audio files get completely or almost completely buffered in the PC from whatever source you are reading it (NAS for example), and then played. Same with video (even when it doesn't buffer the entire video). And video/audio frames are interleaved.

Is not that every packet is "output" as soon as it arrives to the PC.

Or I didn't understand what are you saying.

As an example, let's say you're playing a video.

A playback device creates a stream of audio and video data that is consistent and together. But if there's a network involved, say you have stereo wifi speakers, then the video and audio streams are separated. Maybe the playback device sends the data to the display using hdmi, and that device sends data over the network to the speakers. Now there are two delays - one for decoding and presenting video, and a second separate one for transmitting and then decoding audio. The second one is variable depending on the network.

These are old and solvable problems (audio sync). For example I'm using HDMI ARC to output the audio of my TV, and the TV has a menu to coordinate video/audio (by inserting a delay). In my case I don't need it.

But it's delay, and not integrity of the data being played back. If the network sucks and there are retransmissions, your data might still be integrous without loses (depending on the protocol).

It also happens for musicians on stage. They play and after some delay they hear their own sound back. So they use monitors to hear themselves and the rest of the band.

While in lockdown people gathered together to play music with special software. That tells you something about how this problem is well known and how it can be solved in every situation.

>You could go deeper and manage timing for speakers side to side or front to back

Audio data frames are interleaved, ie RLRLRL. There's no point managing timing of network packets because after going over the network, all the data goes into a buffer at the other end before being played.

But it’s all buffered at a bunch of different places though, right? There must be a stream buffer before the DA to compensate for any upstream latency, no?

Read this.

https://en.wikipedia.org/wiki/AES3

That is a protocol specifically designed to accept input from audio devices like microphones, etc and output directly to audio devices like speakers.

To do the same with ethernet you would have to use an industrial ethernet implementation of which I know at least three and they are all incompatible with each other and even then you would most likely benefit from an audio focused implementation.

All of this is much harder than just buying a better switch and claiming it improves the sound. Your audio playback device and speaker would have to support the same implementation of industrial internet.

No, it’s more — AES67 is a network audio routing protocol using Ethernet frames. Some variations such as Dante can use normal RJ-45 Ethernet gear.

not a networking expert, but isn't all of this a complete waste of effort when you can just make the sample buffer deeper? uncompressed CD audio is only 1.5mbps, so it's not like the cost of dram is going to be a limiting factor.

Yes. It realistically only matters in cases where the bandwidth is so low you're teetering on the edge as it is or it's a live two way conversation where introducing too much buffering will create noticeable lag.

Its still bs. You have stuff like https://en.m.wikipedia.org/wiki/Avionics_Full-Duplex_Switche... already. For audio in a home setup? If your problem is arp or latency, you seriously barfed your setup (bear in mind you can actually use direct crossover configurations to deliver at least 100mbps, more than enough for many uncompressed high-bitrate streams). Audiophile is a niche market with many people with more money than brains, that more often than not, dont really understand tech.

And to go with that you can use $500 ethernet cables, with directional arrows painted on. ACK, and that's not talking about TCP (sorry).

https://www.wired.com/2008/06/snake-oil-alert/

(unfortunately this was from Denon who I've had great luck with an entry-ish-level AVR from for years)

Yea, linus did a roast of one of those that was just rebadged COTS switch.

https://www.youtube.com/watch?v=NMFQ3YvR3Eo

I've heard the following mind numbing phrase used by one person to describe their vinyl music listening experience: "uninterrupted magnetic chain" (ie: from the production all the way to their speakers). The absolute lack of understanding of: electrical engineering, acoustics and signal processing is on full display with these folks.

To me it really highlights the difference of those who seek to understand deeply, and those who interact with the world only in superficial and aesthetic ways. The latter really want to depend on the "magic" within the machine, and can get upset if you try to shed light on how these things really work.

The thing is, some original Vinyl recordings really do sound better than recent heavily compressed "remasters" on CD. Perhaps this person just doesn't know how to explain why the Vinyl sounds better when all the techies say CD is superior (e.g. higher dynamic range, in theory).

'i can hear a difference' is much more honest and plausible than making up a technical sounding phrase to pass for explanation.

> Never mind the fact that two devices connected with RJ45 ethernet have no direct electrical connection

> For the low, low price of $3800, you can be the proud owner of an audiophile grade, 100Base-T network switch

That buys you a seriously good piece of switching gear with 10GBe (or even higher) fiber optic links to whatever devices you could possibly want in a home. Heck, even a little over $100 buys you a switch with 4 SFP+ (Mikrotik CRS305).

I guess audiophiles will claim that the optical transceivers introduce latency and _they can hear it_

The absolute pain when the entire song is delayed by 10ns or what not. If only I could compensate by pushing play a little bit faster.

The issue is not constant latency, but jitter i.e. latency is changing between bits

Jitter matters in very specific cases in very specific pieces of equipment.

Jitter on the Ethernet transferring the file will have no effect.

Like the sibling poster said, this won't cause jitter.

The audio isn't played directly from the ethernet packets. It has to be decompressed, decoded, buffered. In the end of it all the audio goes into a ring buffer and it is played very precisely by the sound card.

The playback itself is a hard-real-time process that needs time guarantees. Failure to fill the ring buffer by any reason can cause audible skips, but not jitter. But most players in practice will simply stop the playback.

The maximum jitter allowed by the IEEE specifications is 1.4 ns for 100-megabit Ethernet and 300 ps for Gigabit Ethernet. The bit time for a 48 kHz audio signal is ~20 000 ns. It is absolutely impossible that you can hear the Ethernet jitter.

As with everything we cannot deal in absolutes. Whilst I in no way want to defend ripof garbage like the linked product you should consider Ethernet for live streaming. TCP correction can very much be audible and UDP is often used.

How can it be audible on TCP when TLS doesn’t break on the same network equipment? Or when you can read documents without typos or parsing errors.

UDP is another story and it’s normal to hear things.

If the correct data only comes in too late after you were meant to hear it.

I use a RME DAC in my setup, and one of the things I like about it is the Bit Test feature. RME supply the WAV bit test files on their site. I've converted them to FLAC. The DAC shows up a message on the LCD when the bit test (played on repeat) is matched perfectly. So no stuck bits, missing bits, bit flips.. just the correct sequence repeated over and over again.

My FLAC files live on a SSD attached to a Raspberry Pi that serves them up over NFS. The data passes through three gigabit switches before arriving at another Raspberry Pi running Volumio, which is connected to my DAC.

There's enough there to keep an audiophile awake at night, but the bit tests have passed perfectly whenever I've run them. No expensive cables, linear mode power supplies, or audiophile switches would make the tests pass any better.

Well, when they're claiming to hear different versions of memcpy, I can't imagine the bits coming across the same is enough for them.

Im assuming you're using sata over usb for the ssd; that latency hoop alone would give nightmares to some audiophiles :) kudos for having a true hifi system without buying into the bullshit

TCP preserves the order.

By retransmitting. Packet loss causes stalls and if there's insufficient buffering, that's an audio glitch.

A patch cable or its connectors would need to be in a dreadful state to get packet loss though, i.e. physically damaged or defective.

Back of napkin estimates:

For lossless CD-quality audio you need about 160kbyte/s.

So on a gigabit network (125Mbyte/s), you'd need over 99.999% packet loss in order to not keep up.

So they're comparing to an almost completely faulty cable.

I feel like a lot of audiophile stupidity is not understanding scale.

There is a difference between the fancy speaker cables and acceptable cheap ones, but it's so ridiculously minuscule as to be completely inaudible compared to, say, whether or not the listener is wearing socks or not.

The only real difference between the cables will be at frequencies over, say, a GHz. ie RF frequencies 50x higher than cats might be able to hear.

But the audiofool will say, "see, there's a difference - I want my system to sound the best".

And they focus so much on ridiculously overkill cables, amplifiers and stands, yet seem to often ignore room treatment which could really make a difference. It's often massive speakers in horribly reflective minimalistic rooms, driven by amps running at 1% of their power rating.

As someome pointed out, even 99% packet loss on a modern network wont affect the stream. I've actually seen (unfortunely) 100mbit "working" with cat3 (phone) ribbon cable... For short distances (<10m), it wont even reach 10% packet loss. And players buffer. Always.

Parent is talking about timing, I assume?

But that is a correctness issue (to the end user), not a quality issue. Wouldn't that cause lag/pauses, or other errors when playing in real time?

That would be correct if things went this way:

Storage -> TCP Stream -> Sound output.

However, it never works like this, except maybe in some rare live conditions (in which case, why are you even running this on TCP?). In reality, it goes:

Storage -> TCP Stream -> Ring buffer -> Sound output

Unless you manage to empty your ring buffer (which, in the case of modern hardware can easily be 32+MB, or multiple seconds of audio), you will not hear a single bit of difference. And if you do, it won't come in "after you were meant to hear it", you'll either get a massive gap, or repeats. There is no such thing as "data coming in too late/out of order".

Audio is rated at kilobits a second while modern networking equipment is rated at gigabits a second. So your networking equipment is multiple orders of magnitude faster than your audio file streaming speed.

If you’re getting audible errors from your network then literally everything you do on that network would feel like 90s dial up days and with lots of corruption. Most websites wouldn’t even load due to TLS errors.

The problem such arguments as yours is that people have subjective experiences that can be influenced by a multitude of personal emotional states and they then retrofit pseudo-technical explanations for why they perceived those experiences. Or in layman’s terms, you basically just buy an expensive placebo.

I aggree the placebo effect is a huge problem. I am not suggesting expensive solutions, I am just saying check your physical installation and maybe not the very cheepest hardware off AliExpress.

The are lots usecases for nearly live audio where TCP stalls cause problems you would never notice browsing the web and would not be a TLS error (which is ushally how networks are 'tested' leaving the problems unfixed).

Live is a very different problem to home listening. Live requires near real time playback on content that is generated in real time. Whereas for any kind of pre-recorded performance, such as listening to music at home, you can read ahead and buffer. So the issues you present simply don’t exist in home set ups.

And before you comment about listening to live performances at home: the broadcaster would be compressing your audio stream anyway. That would be far more impactful to your audio quality than a few dropped networking packets.

Source: I used to work in broadcasting.

If your ethernet switch needs snake oil on your home network to sound good, I have bad news about your ISP, your cable modem, your ISP's transit provider, and your audio streaming app's data center connection.

I am not talking about snake oil. I am saying _LOTS_ of (most?) networks are installed with AliExpress wall sockets etc. and tested by loading google.com once.

If you want trouble free audio streaming it is worth checking the network.

That actually sounds a lot like snake oil. Electrical noise from outlets is irrelevant for digital package relay. Your big ass tv switches 100x more data each frame flawlessly, identifying way more channels than traditional 2-way signaling; when was the last time you heard someone saying "I bought a true filter for my wall socket and my led tv gives me better colors"? Is that level of stupid we're talking about.

I know this sounds stupid, but I actually had something like this happen to me. It was due to the cable.

My PC is very electrically noisy on account of the GPU. This noise was coming out of all the ports, including the Ethernet port. It was making it through that port, by CAT-6 cable, to my switch. The switch then sent it to my Raspberry Pi I was using as a streamer, then into my DAC, amplifier and finally speakers. You could hear it, it was loud when a game started up.

The solution - swap out the CAT-6 with CAT-5 cable which doesn't connect the ground planes. Instantly solved.

I have a computer that will sometimes crash hard, frozen screen and mouse, awful static on the speakers and, interestingly, something coming over the ethernet port too. This interference goes up to the next device on the line, my network switch, and brings that to its knees too. Nothing can move through the switch while that computer is having a seizure. I can disconnect the wire at the switch and the network comes back to life within a minute.

I'm considering putting a sacrificial switch from my junk box inline to that one computer so maybe the rest of the network can survive its crashes.

That is probably the nic in said machine still being alive and unable to pass any received frames up to the os. When its buffer runs full, it starts spamming pause frames, which dumber switches just blast out every port effectively paralyzing the whole network segment.

You could verify this by running Wireshark on another machine, or try disable sending pause frames on the machine before it crashes via eg ethtool

Mmmmh interesting.

In my case just a few weeks ago I had an AP that went bananas, and was directly connected via ethernet to a RPi4, and made the Raspbian kernel panic on the Broadcom driver, randomly. Not long after the AP stopped working completely.

I think electrical engineers having done some RF designs generally regard audiophiles as flat-earthers explaining what is wrong with a flat map; they might get it right now and then, but always for the wrong reasons. Remember how in the 90ties you could hear an SMS coming to a phone near an audio device? Right! No physical connection and sure you can’t hear the 900mhz ish gsm signal, but the rectified and smoothed signal had an audible time division multiplexing (envelope). And the carrier wave often resonated with paths in the signaling path of the audio device.

The common term is 'GSM buzz', you'll find a lot about it online.

I've also heard it in the 2000s.

On a Sunday morning I used to lie in with the radio on, sleeping on and off.

There was one song around 1999 that included the sound and also had my ring tone.

It was a very confusing time.

Found it: https://youtu.be/y8ClVMzt9Dw

[edit: added link]

I heard it just a couple years ago, when I used a 2G phone. 3G and 4G don’t have that fault.

Fault or feature? Was nice to get some warning your phone was about to ring

The keywords are: EMI (electromagnetic interference), signal integrity, power integrity.

Memcpy can have second order effects due to EMI radiated by CPU, motherboard or coupled via power fluctuations.

There are audible and measurable effects of audio system clock jitter which in turn depends on oscillator power quality.

Someone mentioned that ethernet has isolation transformers. But isolation transformers have parasitic common mode coupling which can inject the noise to ground plane if interference is strong and device is susceptible enough

Watch the EEVBLOG on company which designed scope capable of measuring 1kV common mode signals. (present in EV electronics) https://youtu.be/I7ppDNLlEL4

Audiophile stuff is a weird mix of real effects and snake oil.

Yeah.... but somehow changing the memcpy method improved the audio also of the commenters. Unless the commenters have all the same PC, it all smell like "bias".

This, so much this. Many people ignore most of the things affecting sound quality in their setup. Audiophiles don’t, and they often go the extra mile to satisfy their compulsion for better sound—up to and including psychoacoustics.

If a $10,000 power cable makes your amp sound better to you, who’s to say it doesn’t?

the aunt of a friend promised sick people to talk to angels about their issues for only a modest sum. i'm sure those people felt at least a bit better afterwards, because they were of options otherwise.

on the other hand, they spent hundreds of dollars for nothing and if they eventually recovered they'd tell other sufferers about it, dragging them down too.

does the victims glimmer of hope justify her scam?

background: she herself suffered from an "incurable" illness for months, where she paid other angel conjurers (that's where she got the idea from). turns out it was just iron deficiency and easily cured with iron supplements. at that point she'd already paid several hundred dollars to those charlatans.

That is called ”caveat emptor” and it is the founding principle of America.

Just because the placebo effect is real, it's bad to advocate people spending $10k on a placebo.

Hey, some people buy ads on social media.

What do you mean the 90s? I can still hear my phone pining the tower when it's too close to my speakers ? (Eris E5 on balanced XLR into a Scarlett 2i4)

... in the 90s? It still happens today with my phone

No, we don't. And with having enough budget and skills we try our best to shield stuff we make. As for radio noises: just remember that every freakin physical body is an antenna. Not just wires. All we can do generally is tune things in such ways that they resonte in a range we need and be as silent as possible in all other frequencies.

Hum,Im pretty sure you mean STP vs UTP, and not cat5 vs cat6. Electrically, cat5 and cat6 are equal; cat6 is slightly thicker, has a thread separator in the middle, and its rated for higher frequency. Electrically? The same. STP cable (regardless if specced for cat5 or cat6) does have a ground plane.

Oh! That must have been it, thank you. I'm not very familiar, I just knew the cables were cat6 and cat5. Thought it might have something to do with the shielding.

Looking over the product page, it's marked as S/FTP

Yeah don’t use grounded cables if you don’t have ground to actually ground them.

At least that’s what I was told once upon a time since EE is definitely not my forte.

Correct. More specifically, if a shield is not actually grounded, all it becomes is a re-radiating antenna for all of the EMI around it, as well as a means by which to directly transfer electrical noise from one device to another.

I never see either of these terms on sites like Newegg. How do I know which is which? Which one am I supposed to use at home?

The "U" stands for Unshielded, the "S" stands for Shielded. For home use and office use, UTP is fine. STP makes sense in "noisy" (electrical or magnetic) environments, such as factory floors with heavy machinery, clinics & hospitals with specific machinery, etc. See more details on the kind of protection the shielding offers here: https://en.wikipedia.org/wiki/Shielded_cable

Makes sense, but my point was that I've never even seen an option to buy one kind of ethernet cable or other. Is it safe to assume the $15 StarTech cables I buy from Newegg are unshielded? And does the "TP" stand for "Twisted Pair"?

Yes and yes

Or better, use devices designed with a propper grounding scheme and avoid the Raspi DAC for anything critical.

The raspberri pi isn't a dac, it's a streamer. It acts as a middleman to avoid using my PC as the source of the audio.

I'd definitely prefer a DAC with good filtering on its inputs so I wouldn't need to use a middleman, but that is expensive. One with a proper USB module with complete isolation can run ~$5000.

I cannot upvote you enough, as I've been through similar problems many times. But in your case you could just re-crimp one side of your cable with unshielded connector. This is actually a good practice not only for noise and ground-loop preventions, but electrical safety too. Also, CAT.6 doesn't require shielding like FTP/SFTP/etc. - I'm using a CAT.6 UTP right now.

And anti-audiophiles are sometime becoming even worse than manical audiophiles - because of their deep blind belief in their educated superiority (while in reality it's a bit .. untrue).

There's usually a grain of truth in that audiophile nonsense, that it could in theory have some material basis in reality. The problem is the complete rejection of the scientific method.

Whilst I agree on it, this is partially true. shielded cables can create current flows between switches, have seen it previously, and had to fix it as it was inducing problems on the traffic over that cable

To be fair, there's Ethernet switches with AVB support. https://en.wikipedia.org/wiki/Audio_Video_Bridging

AVB is a set of 802.1 extensions that provide better control over bandwidth and latency. This is important when you're playing multiple audio and/or video streams to multiple endpoints connected at different points in the network and they need to be low latency and still kept synchronized.

I've seen professional switches from a large vendor where the AVB license cost as much as the rest of the switch.

I hate the network switch debate. Most center around noise shaping the sound.

It is a one or zero, it will checksum and TCP either gives the correct packet or drops it. Also I do not know many audio streamers that do not buffer since TCP works way faster than a song can play. Plenty of time to make sure the packets are correct.

I have no idea why the audiophile network switches irritates me the most. At least with audio cables I guess you can do measurements that show the single is cleaner, even though there is zero chance of you hearing a difference most of the time (I just make sure cables have good shielding and if the cable has to be seen it better look cool too, haha).

Ya know there are even audiophile USB cables.......not a joke google it.

Both USB and Bluetooth use a connectionless protocol without any retransmit for real-time audio.

I know these products sound stupid, but Ethernet can insert a DC bias and repeat AC-coupled noise from other sources. This includes its own PSU. There are industrial Ethernet products that specifically address both these problems, because in a factory environment, both phenomenon can have practical consequences when there's motors and power electronics throwing around big magnetic fields. I imagine being near speakers with big drivers can also cause some of the same problems that would never be found in a typical desktop or datacenter computing environment.

Just use wifi?

But that would trigger error correction, not degrade the sheer quality like it would happen with analogical signals. Ok, if there are enough errors it would make the playback problematic, but it would be the same for any kind of data transmitted.

I think they're saying that the noise from the Ethernet circuit will leak into the analog speaker connection.

Yes.

Ok, then I misunderstood the big speakers magnetic field issue, sorry. I thought it was the big speaker interfering with the switch, and not the other way round.