are NET Switches worth considering?

I tried a few notable examples and I’m not sure they make a difference. Ended up buying the Ether Regen because I thought I heard a difference.  A few months ago I rearranged my kit , forgot to plug ether regen and did not realise it.  A few days later I realised the error.  Adding the Ether regen I found no difference. I tested with and without a few times over multiple days and truly could not hear any difference. Hence I think it is not necessary

I have had the Phoenix NET in my system for several years and the improvement is not subtle.  Most noticeable is a deeper soundstage and more low level detail retrieval.  My system is primarily:

• dCS Bartok APEX
• Innuos Statement
• Innuos PhoenixNet
• Pass Labs xp-22 Preamp
• Pass Labs x150.8 Amp
• VPI Prime; Soundsmith Zephyr MIMIC Cartridge
• VPI Speed Controller
•  Pass Labs xp-15 Phonostage
• Jays Audio CD Transport
• PS Audio P-15 Powerplant

• PS Audio P-12 PowerPlant

• PS Audio Aspen 30 Speakers

• Morrow Audio Grand Reference Cables & Powercords

@analog that's pretty incredible considering that the Innuos Statement is already an exceptional streamer. The fact that you can hear these improvements is enticing.

I have had good luck modifying my Ethernet chain, this thread got me thinking, my AI discussion below.

Yes, handling a noisy or poorly clocked Ethernet signal requires more processing effort and hardware resources than handling a clean one. This increased workload occurs at both the physical hardware level and the higher software/protocol levels. [1, 2] 

Why Poor Signals Increase Processing

When an Ethernet signal is degraded by noise or timing jitter, the system must engage several "expensive" recovery mechanisms:

• Complex Signal Recovery: At the physical layer (PHY), the hardware must use more power and complex digital signal processing (DSP) to filter out noise and recover a stable clock from the jittery incoming signal.
• Error Correction (FEC): High-speed Ethernet often uses Forward Error Correction (FEC). A noisy signal generates more bit errors, forcing the hardware to perform intensive mathematical calculations to detect and correct those errors before they reach the main system.
• Packet Retransmissions: If noise is severe enough to cause uncorrectable errors, the Ethernet Frame Check Sequence (FCS) will fail, and the packet will be dropped. This triggers TCP retransmissions, which require the main CPU to manage timers, re-buffer data, and process the same information multiple times.
• Link Renegotiation: Extremely poor signal quality can cause the network adapter to constantly drop and renegotiate the link speed (e.g., dropping from 1Gbps to 100Mbps), which consumes additional management overhead. [3, 4, 5, 6, 7, 8, 9, 10, 11] 

Impact on Performance

• Power Consumption: Circuits consume more power when they have to work harder to stabilize a fluctuating clock source or filter high-frequency noise.
• CPU Load: While simple noise is often handled by the network card, the resulting packet loss and retransmissions can significantly increase CPU usage at the operating system level.
• Latency and Jitter: The extra time spent on error correction and waiting for re-sent packets increases network latency and introduces further jitter into the data stream. [2, 4, 7, 10, 12, 13] 

Me again. Maybe a clean signal results in less processing on the network card, and less noise inside the streamer?

According to Antipodes, in documentation related to their latest product release, a high quality switching cannot be done within the high end streamer: It makes sense to me. With digital streaming less is more. 

Streaming to a DAC over Ethernet

Some DACs accept audio over Ethernet, and some users wish to use this approach.
Antipodes DAS have facilitated this in the past giving the server two Ethernet ports: one for the network, and one for the DAC, with the DAC effectively reaching the network through the server.

The Oladra Platform approaches this differently. Instead of the server performing that switching role, the Oladra platform is designed to use a dedicated three-port switch, with the Oladra and the DAC each connected to the switch, and the third port connected to the network.

The reasoning is simple: if Ethernet distribution is required, it is better handled by a high-quality low-noise switch than by the server itself. That keeps the roles clearer, and the solution more purposeful. The switch serves the additional purpose of improving audio performance with streaming services.

Oladra will release an ideal switch for this use. Until then, the same principle applies with a well-designed audiophile switch.

https://camerata.app/outputs