StackAudio SmoothLAN Ethernet Filter

[altib]

Those standards tell nothing about audio perception lol. Heck they didn't even consider audio perception in developing those standards and specifications. Data is data that is being error corrected NEVER EVER correlates to digital audio with more common mode EMI as it travels through the Ethernet cable having a different audio perception than the other digital audio with less common mode EMI as it travels to better implemented Ethernet cable

No offense but in 2025 I couldn't have imagined people can still believe in such marketing bull$h1T...

 

[theveterans]

No offense but in 2025 I couldn't have imagined people can still believe in such marketing bull$h1T...

Lol. I can smell snake oil from afar if there’s no scientific basis for it. There’s an objective data supporting the reduction of CM EMI and its effect in sound perception

 

[audiobill]

https://the-ear.net/review-hardware/stack-audio-smooth-lan-regenerator/

 

[gregorio]

User listening experience I would prefer to hear first hand feedback, not graphs and geeks with instruments doesn't tell me anything about changes in sound.

So you prefer to have listener experience of a signal that cannot be heard/listened to, over objective evidence of how something is actually working? And, what the instruments and graphs demonstrated was that the magnitude of the differences in the analogue output signal were so negligible/tiny that they cannot even exist as sound at any reasonable listening level and therefore, they’ve told you EVERYTHING “about changes in sound” (that there aren’t any)!

Those standards tell nothing about audio perception lol. Heck they didn't even consider audio perception in developing those standards and specifications.

Huh? Of course Ethernet standards don’t tell us anything or even consider audio perception, because neither Ethernet or any Ethernet equipment has any audio perception. The Ethernet standards also tell us nothing or even consider smell, taste or touch/feel of Ethernet data/equipment. Likewise, satellite specifications, vehicle emissions specifications, helicopter avionics specifications and countless other specifications also tell us nothing and don’t even consider audio perception, for exactly the same reason.

Data is data that is being error corrected NEVER EVER correlates to digital audio with more common mode EMI as it travels through the Ethernet cable having a different audio perception than the other digital audio with less common mode EMI as it travels to better implemented Ethernet cable

Data ALWAYS correlates with data over Ethernet, regardless of whether it’s digital audio data, it’s a guarantee of TCP. And again, neither Ethernet data nor Ethernet cables have any audio perception, let alone a “different audio perception”. And lastly, Ethernet data is always buffered, at which point it no longer “travels” and therefore cannot have any EMI.

Lol. I can smell snake oil from afar if there’s no scientific basis for it. There’s an objective data supporting the reduction of CM EMI and its effect in sound perception

There is no objective data that reducing CM EMI in Ethernet signals (beyond it’s specifications) affects sound and yet you apparently are NOT able to “smell [the] snake oil” despite claiming that you can smell it from afar if there’s no scientific basis for it!?

G

 

[theveterans]

So you prefer to have listener experience of a signal that cannot be heard/listened to, over objective evidence of how something is actually working? And, what the instruments and graphs demonstrated was that the magnitude of the differences in the analogue output signal were so negligible/tiny that they cannot even exist as sound at any reasonable listening level and therefore, they’ve told you EVERYTHING “about changes in sound” (that there aren’t any)!

Nobody has told me rather I own a different brand of Ethernet filtering and have personally noticed the sonic difference myself. Again, you're not measuring the right parameter (NOT the ANALOG signal at the output of a DAC, but the CM EMI levels from one end of the Ethernet cable to its other end!).

Huh? Of course Ethernet standards don’t tell us anything or even consider audio perception, because neither Ethernet or any Ethernet equipment has any audio perception. The Ethernet standards also tell us nothing or even consider smell, taste or touch/feel of Ethernet data/equipment. Likewise, satellite specifications, vehicle emissions specifications, helicopter avionics specifications and countless other specifications also tell us nothing and don’t even consider audio perception, for exactly the same reason.

Huge assumption there where there are measurements of CM EMI within the Ethernet cable if you search a little bit on google or bing or search.brave.com that can be a supportive (correlative but definitively factual) of the difference in audio perception between ethernet cables and filtering. Specifications do not ever correlate to audio perception because it has nothing to do with it other than the cable conforms or exceeds that specification.

Data ALWAYS correlates with data over Ethernet, regardless of whether it’s digital audio data, it’s a guarantee of TCP. And again, neither Ethernet data nor Ethernet cables have any audio perception, let alone a “different audio perception”. And lastly, Ethernet data is always buffered, at which point it no longer “travels” and therefore cannot have any EMI.

Again, data is intact as the cable is designed to conform to specs at its most fundamental function, TCP error correction is implement to insure data accuracy. Again, Ethernet data is buffered to whatever size of packet you want, but CM EMI/RFI does not care how small large the buffer size. We're not talking about data integrity here, we're talking about CM EMI entering the audio system through which causes a difference in audio perception

There is no objective data that reducing CM EMI in Ethernet signals (beyond it’s specifications) affects sound and yet you apparently are NOT able to “smell [the] snake oil” despite claiming that you can smell it from afar if there’s no scientific basis for it!?

There are objective measurements out there unlike audiophile stickers and rocks that don't do anything to the sound whatsoever

 

[gregorio]

Again, you're not measuring the right parameter (NOT the ANALOG signal at the output of a DAC, but the CM EMI levels from one end of the Ethernet cable to its other end!).

Unless you have an Ethernet port embedded in your skull, then the analogue signal output of a DAC (which is amplified and transduced) is the ONLY parameter that could be audible.

Huge assumption there

How is it a “huge assumption” that Ethernet cables, signals and equipment don’t have any audio perception? You do know that audio perception is a function of a brain and Ethernet cables, signals and equipment don’t have any brains?

Again, Ethernet data is buffered to whatever size of packet you want, but CM EMI/RFI does not care how small large the buffer size.

EMI/RFI are electromagnetic signals, once the data is buffered the data is stationary, it’s just sitting there in memory and there is no longer any signal, so EMI/RFI signals cannot exist. You do realise that the data is just zeroes and ones and not an analogue audio signal?

We're not talking about data integrity here, we're talking about CM EMI entering the audio system

As Ethernet is galvanically isolated and as there is no CM EMI signal once the data is buffered, how can it enter the audio system? And even if it did somehow enter the audio system, how would it manage to magically bypass a DAC’s output and find an alternative path to your HPs/Speakers?

There are objective measurements out there unlike audiophile stickers and rocks that don't do anything to the sound whatsoever

Great, then you’ll be able to quote objective measurements that demonstrate any of the CM EMI getting past the memory buffer and affecting the analogue signal enough to be transduced into sound!

G

 

[theveterans]

Unless you have an Ethernet port embedded in your skull, then the analogue signal output of a DAC (which is amplified and transduced) is the ONLY parameter that could be audible.

There's no analyzer that measures CM EMI at the analog signal of a DAC. The DAC output in terms of SINAD is irrelevant in this case because it has ZERO correlation with audibility of CM EMI effects on Ethernet

How is it a “huge assumption” that Ethernet cables, signals and equipment don’t have any audio perception? You do know that audio perception is a function of a brain and Ethernet cables, signals and equipment don’t have any brains?

Because you're assuming already that CM EMI is irrelevant where the real world phenomenon is that it isn't and is a huge potential indicator of audible differences with Ethernet

EMI/RFI are electromagnetic signals, once the data is buffered the data is stationary, it’s just sitting there in memory and there is no longer any signal, so EMI/RFI signals cannot exist. You do realise that the data is just zeroes and ones and not an analogue audio signal?

Lol. I already repeated there are measurable interferences of EMI/RFI signals traveling through the Ethernet cable. Data that is ones and zeros are intact through error correction, but the CM EMI that gets in the audio system is a good indicator of audibility differences.

As Ethernet is galvanically isolated and as there is no CM EMI signal once the data is buffered, how can it enter the audio system? And even if it did somehow enter the audio system, how would it manage to magically bypass a DAC’s output and find an alternative path to your HPs/Speakers?

Galvanic isolation DOES NOT filter EMI/RFI entering the system. It only filters out the mains interference (50-60 Hz ONLY and not high frequency range from CM EMI). Therefore, EMI/RFI can 100% be transmitted through Ethernet and therefore is audibly perceived as decreased amount of naturalness and less effortlessness in the sonic presentation

Great, then you’ll be able to quote objective measurements that demonstrate any of the CM EMI getting past the memory buffer and affecting the analogue signal enough to be transduced into sound!

I already mentioned the AP555B CANNOT measure the CM EMI on the analog output of the DAC. It only gives you SINAD which is irrelevant to audibility of Ethernet cables and Ethernet filtering

 

[gregorio]

There's no analyzer that measures CM EMI at the analog signal of a DAC.

An analyser analyses the output signal of say a DAC against the given input signal and therefore can measure differences caused by interference.

The DAC output in terms of SINAD is irrelevant in this case because it has ZERO correlation with audibility of CM EMI effects on Ethernet

If the interference on the Ethernet is not affecting the signal, the noise or the distortion on the DAC’s output, what do you think it is affecting?

Because you're assuming already that CM EMI is irrelevant where the real world phenomenon is that it isn't and is a huge potential indicator of audible differences with Ethernet

I’m not “assuming” CM EMI is irrelevant, it’s irrelevant because it’s common mode (which is rejected) and because measurements demonstrate it doesn’t exist on the analogue output signal. Additionally, CM EMI is no indicator whatsoever of audible differences even in analogue signals, let alone a “huge potential indicator” in Ethernet signals in the hundreds of megahertz! And again, Ethernet cables, signals and equipment does not have any human auditory perception!

Lol. I already repeated there are measurable interferences of EMI/RFI signals traveling through the Ethernet cable.

lol indeed, because NO ONE is arguing there isn’t any EMI/RFI in the Ethernet signals! The argument is that it is irrelevant because after common mode rejection and then the data being buffered there is no longer any CM EMI/RFI!

Data that is ones and zeros are intact through error correction, but the CM EMI that gets in the audio system is a good indicator of audibility differences.

What CM EMI that gets into the audio system? Is this magical audiophile EMI?

Therefore, EMI/RFI can 100% be transmitted through Ethernet and therefore is audibly perceived as decreased amount of naturalness and less effortlessness in the sonic presentation

Again, EMI/RFI can indeed be transmitted through Ethernet but only up to the point of CMR and data buffering. And also again, Ethernet doesn’t have a human brain, it does not audibly perceive anything and digital data does not have any “naturalness” or “effortlessness”, it only has zeroes and ones, that’s it, nothing else, by definition!

I already mentioned the AP555B CANNOT measure the CM EMI on the analog output of the DAC.

Hang on, you stated there are “objective measurements out there” but when I respond “Great, show them to us then”, you now say it cannot be measured! How are you not contradicting yourself? Either there is a measurable effect on the analogue output of a DAC or else there isn’t, in which case there’s no difference for a transducer to transduce.

G

 

[bfreedma]

An analyser analyses the output signal of say a DAC against the given input signal and therefore can measure differences caused by interference.

If the interference on the Ethernet is not affecting the signal, the noise or the distortion on the DAC’s output, what do you think it is affecting?

I’m not “assuming” CM EMI is irrelevant, it’s irrelevant because it’s common mode (which is rejected) and because measurements demonstrate it doesn’t exist on the analogue output signal. Additionally, CM EMI is no indicator whatsoever of audible differences even in analogue signals, let alone a “huge potential indicator” in Ethernet signals in the hundreds of megahertz! And again, Ethernet cables, signals and equipment does not have any human auditory perception!

lol indeed, because NO ONE is arguing there isn’t any EMI/RFI in the Ethernet signals! The argument is that it is irrelevant because after common mode rejection and then the data being buffered there is no longer any CM EMI/RFI!

What CM EMI that gets into the audio system? Is this magical audiophile EMI?

Again, EMI/RFI can indeed be transmitted through Ethernet but only up to the point of CMR and data buffering. And also again, Ethernet doesn’t have a human brain, it does not audibly perceive anything and digital data does not have any “naturalness” or “effortlessness”, it only has zeroes and ones, that’s it, nothing else, by definition!

Hang on, you stated there are “objective measurements out there” but when I respond “Great, show them to us then”, you now say it cannot be measured! How are you not contradicting yourself? Either there is a measurable effect on the analogue output of a DAC or else there isn’t, in which case there’s no difference for a transducer to transduce.

G

Good luck. Logically, memory buffering should put an end to the conversation but it won’t.

The concept that any noise riding along would be preserved in buffered memory then regurgitated when the data is requested is certainly unique.

 

[theveterans]

Good luck. Logically, memory buffering should put an end to the conversation but it won’t.

The concept that any noise riding along would be preserved in buffered memory then regurgitated when the data is requested is certainly unique.

It has NOTHING to do with sound perception other than sounds cutting in and out during buffer overrun.

Do network cables make a difference in sound?​

A network cable affects playback simply because it forms an electrical coupling between the data network and the streamer. Through this link run not only the data packets, but also electrical noise and, for example, RFI and EMI from outside. Shielding helps keep radiation out, but shielding also affects jitter.

Connecting the shield to both sides of the cable is the IEEE standard…. but within audio this does not work very well: the jitter is slightly higher than with the version where the shield is only connected on the device side.

If we turn this cable around and measure again, the jitter increases compared to the version with the shield connected to both sides. So cable direction is no nonsense!

This is real science right here with an actual jitter measurement (one of the characteristics why we can perceive differences with Ethernet filters). CM EMI objective measurements are another key that can potentially explain differences in sonic perception

Explanation of measurements​

Phase noise (converted to jitter): the Aeroflex PN9000 measures phase noise. This phase noise comes in a graph as dBc/hz (Decibel relative to the carrier / offset of the carrier). Lower is better. In other words, a clock with a phase noise of -100 dBc/Hz at 1Hz is better than a clock with a phase noise of -80 dBc/Hz at 1Hz. From phase noise, jitter can again be calculated, since the frequency domain (in which phase noise is measured) and the time domain (in which jitter is measured) are related. After all, 1000 Hz represents 1000 cycles per second. Phase noise simply measures the “noise” around the main frequency. Jitter measures the stability of the clock in the time domain.

Allan Variance (converted to jitter): Allan Variance is used to indicate the stability of a clock. A low value indicates greater stability. A high value indicates large fluctuations. Allan Variance can be converted to ps in fluctuation. We did that to make it readable.

High-Frequency Modulation: this measurement shows the impact of high-frequency interference on the clock. We show the 1-Sigma value, but in the screenshot you can see more details, such as at which frequency the highest deviation was measured.

Low-frequency modulation: this measurement shows the impact of low-frequency interference on the clock. We show the 1-Sigma value, but in the screenshot you can see more details, such as at which frequency the highest deviation was measured.

Total Jitter: the total jitter seen by the Wavecrest. You can think of this as an aggregation of all types of jitter. So Random Jitter as well as Deterministic Jitter. Random jitter is more unpredictable and a bit harder for a manufacturer to deal with. Deterministic jitter comes mainly from identifiable sources of interference and is probably easier to deal with.

1-Sigma: 1-sigma (1σ) means that about 68.2% of all jitter measurements fall within ±1σ of the average timing position. (If we assume a Gaussian distribution). This can be seen nicely in a histogram presentation: a good clock shows a “bell-shape” where the central frequency falls nicely in the middle. Thus, if a clock has a 1-Sigma jitter of 4ps, the deviation in 68% of cases is within 4ps of the ideal.

Above are objective measurements that can really affect the sound perception through different cables and different switches and Ethernet filtering.

Quoted Conclusion:

So what can we learn from this little survey (we’ll take another look at cables from serious brands to see what they offer)?

We see that network cables really do matter. Just like switches, although the influence of a switch is greater. However, we should not underestimate cables: we just consistently see an impact on the clock in the streamer. And that’s not surprising: you make a connection between the network and the streamer. That connection has an impact.

Shielding and filtering seems to be responsible for the differences in measurement results. With that in mind, the choice of materials, geometry and construction of shielding will be the differentiating factor. Again, interesting fare to dive into!

 

[XTF1]

This is real science right here with an actual jitter measurement (one of the characteristics why we can perceive differences with Ethernet filters).

Isn’t it a somewhat uncommon configuration? How widespread is the use of a streamer with integrated DAC connected through an Ethernet cable?

A WiFi connection would fix this problem—no more electrical connection through the network cable—as well as using a separate DAC connected through the streamer via asynchronous USB—no more dependency on a clock residing inside the streamer.

If anything, it shows that this Volumio Primo integrated streamer/DAC could use some improvements…

 

[theveterans]

Isn’t it a somewhat uncommon configuration? How widespread is the use of a streamer with integrated DAC connected through an Ethernet cable?

A WiFi connection would fix this problem—no more electrical connection through the network cable—as well as using a separate DAC connected through the streamer via asynchronous USB—no more dependency on a clock residing inside the streamer.

If anything, it shows that this Volumio Primo integrated streamer/DAC could use some improvements…

Not really. Eversolo, Lumin, Grimm MU2, Bluesound, Mola Mola Tambaqui, Pi2AES Mercury V3 etc. all have streamer/DAC boxes in their lineup

WiFi’s measurements would be interesting. Hopefully someone has enough time and budget to perform tests vs Ethernet and see how both affects the clocks in the streamer. Pi2AES Mercury V3 is a really good specimen to test because it has both WiFi and Ethernet

 

[XTF1]

WiFi’s measurements would be interesting. Hopefully someone has enough time and budget to perform tests vs Ethernet and see how both affects the clocks in the streamer.

The article you referenced is entirely based on the electrical connection of the network cable. To me, it’s very unlikely to pickup EMI/RFI affecting a DAC clock, but ok, let assume it’s indeed the case with THIS streamer:

• Wifi = no electrical connection. The issue being discussed in the article goes away.
• The issues / design problems affecting this particular streamer don’t necessarily apply to other similar streamers.
• It doesn’t prove much about Ethernet cables beyond the fact (?) that, in some remote case, a network cable can affect the sound of a poorly designed audio device.

And this is assuming the measurements presented in the article are correct and relevant.

 

[theveterans]

The article you referenced is entirely based on the electrical connection of the network cable. To me, it’s very unlikely to pickup EMI/RFI affecting a DAC clock, but ok, let assume it’s indeed the case with THIS streamer:

• Wifi = no electrical connection. The issue being discussed in the article goes away.
• The issue affecting this streamer don’t necessarily apply to other similar streamers.

IMHO, It’s an assumption as you already noted. Show us objective measurements in the streamer’s jitter or phase noise plot from using WiFi against a filtered Ethernet. Still interested to see and truly understand if manufacturers are duping us for eliminating WiFi on their streamers so we drop some $$$ on Ethernet filtering instead to make more $$$$ profit

High End Audio Manufacturers claim that WiFi Radio is a noise generator in and of itself hence why they are claiming to not include them on their streamers

 

[XTF1]

IMHO, It’s an assumption as you already noted. Show us objective measurements in the streamer’s jitter or phase noise plot from using WiFi against a filtered Ethernet. Still interested to see and truly understand if manufacturers are duping us for eliminating WiFi on their streamers so we drop some $$$ on Ethernet filtering instead to make more $$$$ profit

High End Audio Manufacturers claim that WiFi Radio is a noise generator in and of itself hence why they are claiming to not include them on their streamers

If I’m not mistaken, the Volumio Primo does have a WiFi receiver. So it was exposed to the ambient WiFi “noise”.