Best audiophile switch

[sbnx]

I don't think you'll find a setup that basic in an audiophile system, not if they have any interest at all in high-fidelity network audio. I know some just use Spotify or internet radio for background music, because their interest is in CD or vinyl.

CAT8 is always shield-tied to ground at both ends, therefore it requires specific grounding conditions to avoid a ground loop. Even though it has the best shielding capability, it should not be used universally.

Being a dealer, I see this all the time. And these are systems with big name brands where the person is well north of 6 figures in their system.

There are still a lot of people who either refuse to believe or don't believe that a switch or ethernet cable make any difference. In fact, there is a whole forum where people with similar beliefs hang out -- ASR.

 

[Di-fi]

Electronic interference is certainly an enemy in the Ethernet path. But I think John Swenson means something else. He has published a white paper: https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf

I quote some from it:

Thanks — really helpful. I think we’re saying the same thing in different words. When I said the clock “quiets the electrical backdrop,” I meant what Swenson explains more technically: phase noise from clocks can modulate the timing of signals, and that distortion carries through to the DAC.

So a better clock doesn’t “time the audio,” but it reduces the noise that affects how precisely the DAC can do its job.

I’m not out to debate — just hoping this is helpful as we all try to understand why what we hear with a clock might even be possible.

 

[treitz3]

Being a dealer, I see this all the time. And these are systems with big name brands where the person is well north of 6 figures in their system.

There are still a lot of people who either refuse to believe or don't believe that a switch or ethernet cable make any difference. In fact, there is a whole forum where people with similar beliefs hang out -- ASR.

They are doing this hobby and those who don't know anything a huge disservice.

Tom

 

[Superdad]

Thanks — really helpful. I think we’re saying the same thing in different words. When I said the clock “quiets the electrical backdrop,” I meant what Swenson explains more technically: phase noise from clocks can modulate the timing of signals, and that distortion carries through to the DAC.

Even that misconstrues what we have been saying:

ALL of this--the reason we hear ANY differences with packet-data interface (USB, Ethernet) elements--comes back to modulation (mostly low frequency) of the ground-plane of the circuit board domain where the DAC's audio master clock sits.

Sources of that are manifold:
--Leakage currents (common-mode AC traveling on DC data and power connections);
--Every processor chip--be it an FPGA, CISC, RISC, Ethernet switch chip, or PHY--puts noise into the ground-plane constantly via its bursty activity and current draw;
--Phase-noise/jitter of the data (embedded and after reclocking) converts to amplitude noise, also on the ground-plane.

This can all be measured at the master clock pin of the DAC (using an expensive differential probe), but capturing the differences on an analyzer is difficult.

 

[treitz3]

Even that misconstrues what we have been saying:

ALL of this--the reason we hear ANY differences with packet-data interface (USB, Ethernet) elements--comes back to modulation (mostly low frequency) of the ground-plane of the circuit board domain where the DAC's audio master clock sits.

Sources of that are manifold:
--Leakage currents (common-mode AC traveling on DC data and power connections);
--Every processor chip--be it an FPGA, CISC, RISC, Ethernet switch chip, or PHY--puts noise into the ground-plane constantly via its bursty activity and current draw;
--Phase-noise/jitter of the data (embedded and after reclocking) converts to amplitude noise, also on the ground-plane.

This can all be measured at the master clock pin of the DAC (using an expensive differential probe), but capturing the differences on an analyzer is difficult.

All I need is my ears, Alex. That is proof enough to me. While you have explained it (ad nauseam) and tried to tell folks what is what? I feel very blessed that I no longer have to deal with, nor get my learn on about it (although, there may be advancements forthcoming ). I simply listen in bliss, thanks to people, the likes of yourself and John...along with certain forum members.... I don't think I have mentioned this publicly before, but THANK YOU.

I mean that genuinely. Thank you. I am truly enjoying what it is I hear. Some things? I never thought possible.

Tom

 

[Di-fi]

Even that misconstrues what we have been saying:

ALL of this--the reason we hear ANY differences with packet-data interface (USB, Ethernet) elements--comes back to modulation (mostly low frequency) of the ground-plane of the circuit board domain where the DAC's audio master clock sits.

Sources of that are manifold:
--Leakage currents (common-mode AC traveling on DC data and power connections);
--Every processor chip--be it an FPGA, CISC, RISC, Ethernet switch chip, or PHY--puts noise into the ground-plane constantly via its bursty activity and current draw;
--Phase-noise/jitter of the data (embedded and after reclocking) converts to amplitude noise, also on the ground-plane.

This can all be measured at the master clock pin of the DAC (using an expensive differential probe), but capturing the differences on an analyzer is difficult.

Thanks — that’s helpful added context. The discussion here was focused specifically on clocks, which is why I only mentioned phase noise. But of course, it’s good to keep in mind that other sources like chip noise and leakage currents also contribute to the overall noise environment around the DAC’s master clock.

 

[NigelB]

Electronic interference is certainly an enemy in the Ethernet path. But I think John Swenson means something else. He has published a white paper: https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf

I quote some from it:
Phase-noise is an alternative way to look at jitter. You can think of it as the “frequency spectrum” of jitter.
Phase-noise is usually thought of as only a property of clocks, but this is an important noise component
because the clocks are used to determine exactly when “edges” happen in data signals. The data is “clocked
out” by the clock, so timing variations in the clock, (jitter) show up in the data signals

This simply does not and cannot apply in the ethernet domain. There might well be "edges" in digital signals after the streamer because the concept of edges involves timing, but there are no edges in ethernet data packets as there is no timing.

The impact of the devices Swenson designed is beyond doubt - indeed they were the first to demonstrate that a network switch, properly installed, could improve sound quality, and we should all be hugely grateful for this revelation - but the rationale here makes no sense at all.

I'm with @treitz3: what ultimately counts is our ears. I'm not sure whether "the proof of the pudding is in the eating" travels/translates internationally, but this is a perfect summary!

 

[Superdad]

This simply does not and cannot apply in the ethernet domain. There might well be "edges" in digital signals after the streamer because the concept of edges involves timing, but there are no edges in ethernet data packets as there is no timing.

OMG Nigel! What you say there could not be further from the truth!
(Setting aside the fact that someone quoted out of context the tutorial section of a paper of ours and that my own points about phase-noise induced ground-plane noise is one again being ignored by you.)

Ethernet is ALL about timing, data edges, and clocking!
I am short on time, hungry, and my back hurts, so I'll just be lazy and post this concise summary on the matter from my preferred AI (Perplexity):
--Alex C.
P.S. Don't forget that my partner John Swenson spent his career deep in design of actual ASICs and Ethernet switch chips and Ethernet and USB PHY chips. Some famous classic Cisco switch series (2960 as I recall) us big parts that he lead the design of.

Timing and Data Edges in Ethernet Packets
Timing and data edges are fundamental in how Ethernet hardware transmits and receives data. Here’s how these concepts relate specifically to Ethernet packets:

Timing in Ethernet
Timing in Ethernet refers to the precise synchronization required for sending and receiving data packets between devices.

Ethernet uses clock signals to coordinate when data bits are transmitted and sampled. Each packet relies on an accurate timing reference to maintain the correct bit sequence and data integrity.

For example, in interfaces like RGMII (Reduced Gigabit Media-Independent Interface), both rising and falling edges of the clock signal are used—this is called double data rate (DDR) transfer, and it doubles the data throughput because data is sampled on both the rising and falling edges of the clock. Timing is particularly critical here, with clock delays (usually 1.5ns to 2ns in RGMII) required to align the data and clock signals.

At the physical layer (PHY), packet arrival can happen at any instant, and the receiver must quickly synchronize and align itself to the timing of incoming edges, typically using an interrupt triggered by the edge on the input data line.

Data Edges
Data edges refer to the transitions in the physical electrical signal—either from low to high voltage (rising edge) or from high to low (falling edge)—which represent digital data bits in Ethernet signaling.
These edges are crucial for:

Clock Recovery: The receiver often uses these edges to re-synchronize its internal clock, using features like phase-locked loops (PLLs).

Data Sampling: The exact moment when data is considered valid is generally aligned with specific clock edges (either rising, falling, or both, as in DDR interfaces).

When a transmitter sends Ethernet data, it puts each bit on the wire in sync with a clock. The receiver must detect data edges (transitions) and use them to sample the correct data values for each bit.

For 10BASE-T Ethernet, the initial preamble signal (a regular sequence of data edges) helps the receiver lock onto the timing before actual data arrives—missing these initial edges means the packet cannot be correctly processed.[2]

Importance for Data Integrity

Packet boundaries are also detected using timing and data edges. For instance, the preamble and start frame delimiter in Ethernet help the receiver detect exactly when the packet starts.

Edge synchronization ensures that both sender and receiver are aligned, minimizing bit errors and maximizing throughput.

Example: RGMII Signaling and Data Edges

In RGMII, data signals (TXD, RXD) are paired with clock lines (TXC, RXC).

Communication happens on both edges (rising and falling) of these clocks, demanding careful layout and sometimes deliberate introduction of delays to ensure setup and hold timing for data is met.

Summary Table

Concept	Description	Example Usage
Timing	Synchronizes sender/receiver for data transmission	Clock signals, preamble sequences, PHY synchronization
Data Edges	Electrical transitions denoting bits, aid in sampling	DDR interfaces, preamble for edge detection

In essence, timing ensures packets are correctly sent and received, while data edges are the physical events that define the digital data within each packet. Improper alignment or detection of either compromises packet integrity and network reliability

 

[audiobomber]

There are still a lot of people who either refuse to believe or don't believe that a switch or ethernet cable make any difference. In fact, there is a whole forum where people with similar beliefs hang out -- ASR.

ASR type objectivists are not audiophiles by my definition, so their opinions don't count.

 

[NigelB]

Ethernet is ALL about timing, data edges, and clocking!

Sorry to hear about your discomfort (and hunger)! but as we disagree 100% on this opening statement, I won't be reading any further.

I'm fully aware of Swenson's work, I just don't consider it relevant to the problem we seek to solve. We do agree on one part of the closing sentence of your extract " timing ensures packets are correctly sent and received". This is fundamental to the working of the internet of course and is entirely unrelated to sound quality.

As I say, the proof of the pudding is in the eating; I'm as happy to stand by my own products as you are to stand by yours, and I'm sure we're both equally pleased at how many music lovers are appreciating what our work can do.

All the best,
Nigel

 

[jasond]

Obviously Network Acoustics is about to release a new reference filter and ethernet cable (streaming system) that is a major step up from everything they have done so far. That is exciting to hear and very much looking forward to getting more details about it.

 

[treitz3]

I'm fully aware of Swenson's work, I just don't consider it relevant to the problem we seek to solve.

Hi, @NigelB. Good morning to you. Maybe I missed "the problem" here, but what is the problem we seek to solve?

Tom

 

[Republicoftexas69]

All I need is my ears, Alex. That is proof enough to me. While you have explained it (ad nauseam) and tried to tell folks what is what? I feel very blessed that I no longer have to deal with, nor get my learn on about it (although, there may be advancements forthcoming ). I simply listen in bliss, thanks to people, the likes of yourself and John...along with certain forum members.... I don't think I have mentioned this publicly before, but THANK YOU.

I mean that genuinely. Thank you. I am truly enjoying what it is I hear. Some things? I never thought possible.

Tom

I rather enjoy learning about the nuances of streaming audio and the products represented by the various contributors here like @NigelB and @Superdad as well as others. That is what these forums are about no?

 

[treitz3]

Same here. My apologies if it was implied otherwise. I wouldn't be where I am at now without said discussions.

Tom

 

[NigelB]

Hi, @NigelB. Good morning to you. Maybe I missed "the problem" here, but what is the problem we seek to solve?

Tom

And good morning/afternoon/evening to you, Tom!

Noise and its effect on the sound quality of streamed audio.

 

[treitz3]

Isn't that what has been addressed here by Alex? Noise has an extreme effect on streamed audio IME.

Tom

 

[NigelB]

I'm fully aware of Swenson's work, I just don't consider it relevant to the problem we seek to solve.

Hi, @NigelB. Maybe I missed "the problem" here, but what is the problem we seek to solve?

Noise and its effect on the sound quality of streamed audio.

Isn't that what he has been addressing here by Alex? Noise has an extreme effect on streamed audio IME.

Yes. I believe we are 100% aligned in identifying the problem to be solved. The whole thread is about audiophile switches and this is what they are designed to do.

It's simply that different manufacturers might focus on different design factors in seeking to address this.

 

[kennyb123]

I'm fully aware of Swenson's work, I just don't consider it relevant to the problem we seek to solve. We do agree on one part of the closing sentence of your extract " timing ensures packets are correctly sent and received". This is fundamental to the working of the internet of course and is entirely unrelated to sound quality.

Packets happen at layer 2 (data link layer) in the OSI model, I believe. Swenson’s attention seems to be more focused on what’s happening at layer 1 (physical layer). It’s at this layer that not only can noise come along for the ride, the networking gear can itself be a source of noise.

What @Superdad posted is way above my pay grade, but what I come away with is that transceivers themselves will have to work less hard the better the conditions around them when it comes to detecting edges. And when they have to work harder, more noise can result.

I could be totally off here, my point is only to suggest that maybe what Swenson is doing is double-clicking a few levels deeper into the “why”. A musically-satisfying switch can be developed without taking it down to that level as long as it does an exemplary job of addressing the “how”. Issues at layer 1 that can harm sound quality can be lessened even when treating level 1 as a black box. I suspect though that one improves their odds by double-clicking into these things, but even that’s not a guarantee as one can miss the forest through the trees. Given how well your products have been received, I suspect you may be proving Swenson correct on the “why” despite not agreeing on the “how” to achieve that. This isn’t an easy problem to solve fully so disagreements are to be expected.

I appreciate that you actively contribute on here.

 

[treitz3]

Yes. I believe we are 100% aligned in identifying the problem to be solved. The whole thread is about audiophile switches and this is what they are designed to do.

It's simply that different manufacturers might focus on different design factors in seeking to address this.

Understood. It is my experience that no matter how a manufacturer tries their best to eliminate 100% of said noise, not one product I have ran across to date gets rid of all of it. Unfortunate, yes, but it is what it is. Some obviously do better than others, and both of you seem to have a rather robust and positive product(s) to help in getting rid of as much noise as possible.

I appreciate that you actively contribute on here.

Agreed and yes, these types of discussions are more than welcome.

Tom

 

[NigelB]

Packets happen at layer 2 (data link layer) in the OSI model, I believe. Swenson’s attention seems to be more focused on what’s happening at layer 1 (physical layer). It’s at this layer that not only can noise come along for the ride, the networking gear can itself be a source of noise.

What @Superdad posted is way above my pay grade, but what I come away with is that transceivers themselves will have to work less hard the better the conditions around them when it comes to detecting edges. And when they have to work harder, more noise can result.

I could be totally off here, my point is only to suggest that maybe what Swenson is doing is double-clicking a few levels deeper into the “why”. A musically-satisfying switch can be developed without taking it down to that level as long as it does an exemplary job of addressing the “how”. Issues at layer 1 that can harm sound quality can be lessened even when treating level 1 as a black box. I suspect though that one improves their odds by double-clicking into these things, but even that’s not a guarantee as one can miss the forest through the trees. Given how well your products have been received, I suspect you may be proving Swenson correct on the “why” despite not agreeing on the “how” to achieve that. This isn’t an easy problem to solve fully so disagreements are to be expected.

I appreciate that you actively contribute on here.

Thanks, excellent post!