Ethernet Routers for Audio

[PCOWandre]

8 minutes ago, Assisi said:

have been pursuing the reduction in noise floor in every way ever since my first realisation to enhance my listening pleasure.

Reduction is noise floor is measurable, though. Very simple. Play a zero-bit track of silence with the volume wound up to 100% and measure the noise. Then swap gear in and out and take more measurements. If plugging in an ethernet cable increases the noise, there's a problem that can be fixed. This is why I've stated a few times that the one thing I can buy is using isolation in some cases where noise is a demonstrable problem, although killing the source of the noise always seems smarter than covering it up. 

[Guest Old Man Rubber]

Interesting discussion although being an IT guy who has done his share of networking I think I'd fall on the side of skeptical when it comes to claims of being able to affect the quality of audio playback using a different ethernet cable.

 

However, one thing that got dropped earlier in the conversation was the use of mesh networks in your home to get around Wifi transmission issues.  I can only wholeheartedly recommend that you throw away anything you are currently using in a bigger house for Wifi if you haven't got a mesh network.

 

We bought the Google Wifi stuff when it came out (3 pucks) and I stopped running ethernet through my house after that.  I am lead to understand the newer Nest product is even better.  I still have an ethernet switch with the A/V gear in the lounge to get rid of any NAS traffic and to help with a Fetch box, but everything else is going over the mesh Wifi and it's incredible compared to trying to use those stupid repeaters that halve your network speed.

 

This house is loooooong too, just put the  pucks in three different spots (one in the lounge/dining at the front of the house, one in the middle and one in the back in the study.  Can't recommend them highly enough.

[:) Go Away (:]

Hmm.. interesting thread. 

 

Question, say a digital file containing bytes of information, gets moved from server A to B and than to C and than to D and so on. Does that byte of the information within that digital file changes after all these move?

[PCOWandre]

1 minute ago, :) Go Away (: said:

Question, say a digital file containing bytes of information, gets moved from server A to B and than to C and than to D and so on. Does that byte of the information within that digital file changes after all these move?

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

[Stereophilus]

42 minutes ago, Old Man Rubber said:

Interesting discussion although being an IT guy who has done his share of networking I think I'd fall on the side of skeptical when it comes to claims of being able to affect the quality of audio playback using a different ethernet cable.

 

However, one thing that got dropped earlier in the conversation was the use of mesh networks in your home to get around Wifi transmission issues.  I can only wholeheartedly recommend that you throw away anything you are currently using in a bigger house for Wifi if you haven't got a mesh network.

 

We bought the Google Wifi stuff when it came out (3 pucks) and I stopped running ethernet through my house after that.  I am lead to understand the newer Nest product is even better.  I still have an ethernet switch with the A/V gear in the lounge to get rid of any NAS traffic and to help with a Fetch box, but everything else is going over the mesh Wifi and it's incredible compared to trying to use those stupid repeaters that halve your network speed.

 

This house is loooooong too, just put the  pucks in three different spots (one in the lounge/dining at the front of the house, one in the middle and one in the back in the study.  Can't recommend them highly enough.

Thanks, although that goes completely against opinion earlier in this thread... back to the drawing board.

[dbastin]

Well, there has been a lot of discussion.  There is too many specific comments I am tempted to reply to.

 

As I imagined again there is 2 camps.

 

We could continue debate which camp is more correct, however it is likely both are, and also very likely there are people much more expert and experienced than us in this weird little niche of networking.

 

To my ears, in my system, there is definitely things in networking that change sound quality.  My aim is to discover practical ways to put together a network to yeild best sound quality with devices etc that the average person can use.

 

I am willing to invite people that are skeptical to hear the difference it makes in my system.

 

So, can I suggest we try to respect our beleifs, differences and values and harness our collective knowledge to bravely explore possibilities.

 

As you may know, I have created threads about ethernet cabling, switches and tweaks for discussion on those things.

 

So getting back to the topic of this thread, its not clear ro me if  @rmpfyf or anyone else provided a clear answer to my query which was along the lines of, what would be better than MikroTik?

 

I am not particularly seeking in a lengthy technical explanation (although happy to read them even though alot of it goes over my head). And I honestly dont care if its 'audiophile' or not if it performs in a way to improve sound quality.  I would gladly like to find a lower cost solution and not be conned by hype.

 

In the back of my mind, I suspect there are some products which despite marketting may not perform better than 'industry standards'.  However it would take a gutsy commitment to invest in production of audiophile products that are not value for money compared to industry standards ... knowing there is a world full of skeptics ready to highlight better performing solutiions at lower cost.

 

Finally, while I have my own personal interests in this info, it also benefits people who read but dont participate in discussion. And my experience with trials will also be shared and ideally verified by others (based on their systems, or hearing mine) to contribute to our collective knowledge.

 

Dale

[Stereophilus]

1 hour ago, PCOWandre said:

It's pretty much voodoo wishy thinking, on the face of it. I'll give it proper re-read later, but the facts just aren't stacking up. If ethernet frames were a primary cause of "ground plane noise", the problems wouldn't be restricted to audio, you'd have bright flashes on screens and generally the whole thing would lock up because the timing for accessing memory (RAM) is thousands of times more strict than S/PDIF or USB audio.

I’m just going to ignore the bit about Shakti stones, as I don’t think it’s relevant to an intellectual discussion.

 

The way I read it, the author is justifying his position by suggesting upstream components of a DAC (talking specifically here about a device that is highly sensitive to timing errors) can influence the ground plane voltage and therefore threshold voltage for the DAC.  I think the video analogy is appropriate, as a video processing chip would process the same timing errors as colour variations in an individual pixel for fractions of a second.  1 pixel a bit darker or a bit lighter is probably not detectable all that easily for most of us and there is ignored for the most part.  The claim in the article is that these small timing variations affecting a DAC are audible.

 

The argument about integrity of data transferred , buffered or stored are not part of the argument, as he is suggesting the variations occur at the DAC.

[:) Go Away (:]

32 minutes ago, PCOWandre said:

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

This pretty much summarises how the digital domain works. Cables makes the data transfer faster or slower, but does not alter the digital file. If it did, I am sure, I wouldn't mind seeing my bank balance being distorted and having few zeroes in back added.

 

What I mean to say, is that the digital bytes that forms the audio stream/file does not change at all by changing the cables or CPU or RAM. By changing the cables or switches what it would impact is how fast that file can be presented from point A to point B and thats it. 

 

Yes, cables, routers and switches does make difference on how the data is being transferred, but in no way it changes the data. Yes, we often change the fibre cables or DAC cables between switches or server as it causes multiple errors in data transfer and changing the cables often resolves this.

 

It is lot like, playing a very large video file on a media player over wifi network vs playing it locally on that same media player. The video file does not change, but playing it over wifi can cause few skips and pauses as it has to buffer enough data in order to play the next content vs playing it locally has a smooth playback. File remains same, but the playback changes by changing the method of transfer. 

 

One would rather benefit by improving the overall network to say from 100mb to 1000mb network. But changing the cables within same network most likely will not result in any improvement other than some latency errors being improved.

 

As for the suggestion on equipment.

Some standard switches: https://www.fs.com/au/products/90130.html or something higher on chain, https://www.fs.com/au/products/90132.html

DAC cables: https://www.fs.com/au/products/48884.html

Fibre cables: https://www.fs.com/au/products/40192.html

Cat8 RJ45: https://www.fs.com/au/products/72756.html

 

Edited September 16, 2020 by :) Go Away (:
Updated link.

[BugPowderDust]

12 minutes ago, PCOWandre said:

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

Absolutely. Networking depends on being able to guarantee payload integrity from end to end. If it didn't work, you wouldn't / couldn't do internet banking on it. 

 

The real crux of matters is, networking was designed and iterated to death to fix real problems (latency, packet loss etc) and has evolved to be overwhelmingly awesome at creating a super high performance mechanism of sharing digital data precisely  and optimally between two endpoints. The underlying protocols from the physical layer up the stack to the application layer all have their own performance optimisation and inherent fault checking mechanisms to make sure if something goes bad in transmission, that the bad bit of data gets sent again.

 

Most of the physical layer issues in the analog audio world, are mitigated and even negated through cabling choices, link layer protocols, network layer protocols, transmission protocols and then an application that sits on top of it all which can elect to do it's own end to end payload verification.  This means we've built a highly resilient transmission technology that abstracts away things like noise that are a problem in analog audio to something that is overcome with judicious use of many layers of technology mechanisms.

 

We know that the payload that you get is bit perfect. If it's not, we get to see at multiple parts of the transmission stream where the error exists and depending on the identified location, you can then fix at your leisure (new cables, new physical interfaces, new computer... select your poison).  TCP knows a bad packet has arrived due to checksums and will ask for a replacement if this happens. 

 

Best of all, we can see these statistics in real time on a proper, managed networking device or endpoint; networking engineers even got so smart to put alerts on these kinds of events using a whole other set of protocols like SNMP to "save our bacon" when things broke.

 

We know we have ways of making some packets go faster than others (queuing is a well defined and used system to achieve this, borne firstly for time sensitive applications like voice and video).  We also know we have ways of making things get distributed over the network faster or more optimally (see multicast for an example). 

 

There isn't a problem that the traditional issues in the audio realm (noise, interference etc) have that doesn't have a compensating control in the networking stack to ameliorate it.  If there was, it would have been fixed for much more important time critical or data sensitive applications like high frequency trading, financial settlements, video distribution networks or the plethora of IoT centric devices like PLCs that make your food, make your electricity or filter your water supply.  

 

Audio is a long way down the list of essential services IP networking provides and offers no unique problems to solve that haven't already been solved for other purposes.  Audiophiles are about as confused about networking as that kid with Beats headphones on his iPhone is with his Dad buying a $20k vinyl rig.

 

I'd write a best practice guide for your audio network and device selection if I figured it would get read and not debated. It's not that hard. We've had the recipe for years.

[BugPowderDust]

7 minutes ago, Stereophilus said:

The argument about integrity of data transferred , buffered or stored are not part of the argument, as he is suggesting the variations occur at the DAC.

While amazingly sceptical, if that's the case, isolate the DAC using fibre like you can do on a Lumin X1 with an inbuilt SFP.  Another physical layer problem that networking has already solved.

[pwstereo]

2 minutes ago, Stereophilus said:

... suggesting upstream components of a DAC (talking specifically here about a device that is highly sensitive to timing errors) can influence the ground plane voltage and therefore threshold voltage for the DAC.

The claim in the article is that these small timing variations affecting a DAC are audible.

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected. The content of those frames and packets is reconstituted, buffered and presented again as a digital audio stream by the endpoint equipment, not by the networking equipment. Or am I misunderstanding what is being said?

[Stereophilus]

10 minutes ago, recur said:

While amazingly sceptical, if that's the case, isolate the DAC using fibre like you can do on a Lumin X1 with an inbuilt SFP.  Another physical layer problem that networking has already solved.

I’d encourage a re-read of the article, as he specifically covers this.

[PCOWandre]

11 minutes ago, pwstereo said:

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected.

This is correct, yes. 

[Stereophilus]

11 minutes ago, pwstereo said:

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected. The content of those frames and packets is reconstituted, buffered and presented again as a digital audio stream by the endpoint equipment, not by the networking equipment. Or am I misunderstanding what is being said?

As I read it, he is suggesting the ground signal variation / noise that piggy-backs along all the data cables (except optical fibre) is the issue, not the data.  The ground signal variation affects how the DAC reads those packets.

[Stereophilus]

Regarding fibre:

 

Q. What about fiber-optic interfaces? Don’t these block everything?
A. In the case of a pure optical input (zero metal connection), this does block leakage current, but it does not block phase-noise affects. The optical connection is like any other isolator: jitter on the input is transmitted down the fiber and shows up at the receiver. If the receiver reclocks the data with a local clock, you still have the effects of the ground plane-noise from the data causing threshold changes on the reclocking circuit, thus overlaying on top of the local clock.

 

I can’t comment on the veracity of this answer, but it seems to suggest that the fibre receiver is just as prone to ground-plane noise transmission as any other upstream device.

[danrey]

2 hours ago, Stereophilus said:

If there was an explanation of why networks can affect the SQ of streamed music, would that change your perspective?  The best explanation of why network switches / routers and isolators affect audio SQ is here:

See here as to why it's voodoo science:

https://www.audiosciencereview.com/forum/index.php?threads/uptone-audio-etherregen-switch-review.10232/

[Stereophilus]

12 minutes ago, danrey said:

See here as to why it's voodoo science:

https://www.audiosciencereview.com/forum/index.php?threads/uptone-audio-etherregen-switch-review.10232/

Yeah, i do keep abreast of that website, more for fun than anything else.  His DAC and power amp measurements are quite useful IMO.  There is a view that he measures the wrong things when it comes to upstream devices.

 

The article i posted was for interest and comment more broadly on ground plane noise, not for the specifics of the ER product (which can be discussed in the thread dedicated to it).

Edited September 16, 2020 by Stereophilus

[PCOWandre]

21 minutes ago, Stereophilus said:

fibre receiver is just as prone to ground-plane noise transmission as any other upstream device.

The problem with the theory is that this concept of frame timing induced ground-plane noise transmission doesn't exist. And even if it somehow did exist, the idea of "re-generating" ethernet a spurious claim, because a switch, unlike a class II repeater, re-writes the frames from buffer every time anyway. The MAC receives the frame and doesn't bother the CPU until the frame has been copied to buffer memory, so there's no CPU involvement. And the cadence of frames is highly random in all cases anyway -- there's a reasonable assurance that on ethernet the frames will turn up in the right order most of the time, but their timing is going to be very loose (the client doesn't ask for data in a regimented fashion, the server doesn't send on the client's schedule, the network is going to be full of ad-hoc broadcast traffic anyway). 

 

Mr. rmpfyf asserts a hypothesis in a client device with very limited resources and/or bad design, there can be latency or jitter induced on the outgoing audio bitstream because of CPU interrupt workload, random packet timing, underfilled buffers or the like and proposes a strict-timing solution in the form of AES67. I respect his hypothesis while not endorsing his solution because I feel the technically correct solution to any and all timing problems is to have massive buffers on the client with audio processes running in the real time class. 

[DSD_Fan]

7 hours ago, Hydrology said:

Trying to get my hands on a Waversa WSmartHub.

New Australian distributor so stock shouldn’t be too far away.

 

 

 

 

 

 

 

 

 

Who's selling them and how much???

 

 

 

[Assisi]

24 minutes ago, danrey said:

See here as to why it's voodoo science:

https://www.audiosciencereview.com/forum/index.php?threads/uptone-audio-etherregen-switch-review.10232/

Just to flavour the pudding a bit more read these two reviews by Audio Bacon.  He listens.  They are not for the Etheregen.

 

https://audiobacon.net/2019/11/02/the-jcat-signature-lan-a-1000-ethernet-cable/

https://audiobacon.net/2019/04/05/sotm-snh-10g-audiophile-ethernet-switch-review/

John

 

[Hydrology]

7 minutes ago, DSD_Fan said:

 

Who's selling them and how much???

 

 

 

For now Audio Connection in NSW.

[Stereophilus]

18 minutes ago, PCOWandre said:

The problem with the theory is that this concept of frame timing induced ground-plane noise transmission doesn't exist. And even if it somehow did exist, the idea of "re-generating" ethernet a spurious claim, because a switch, unlike a class II repeater, re-writes the frames from buffer every time anyway. The MAC receives the frame and doesn't bother the CPU until the frame has been copied to buffer memory, so there's no CPU involvement. And the cadence of frames is highly random in all cases anyway -- there's a reasonable assurance that on ethernet the frames will turn up in the right order most of the time, but their timing is going to be very loose (the client doesn't ask for data in a regimented fashion, the server doesn't send on the client's schedule, the network is going to be full of ad-hoc broadcast traffic anyway). 

 

Mr. rmpfyf asserts a hypothesis in a client device with very limited resources and/or bad design, there can be latency or jitter induced on the outgoing audio bitstream because of CPU interrupt workload, random packet timing, underfilled buffers or the like and proposes a strict-timing solution in the form of AES67. I respect his hypothesis while not endorsing his solution because I feel the technically correct solution to any and all timing problems is to have massive buffers on the client with audio processes running in the real time class. 

If we can move past the “re-generation” concept, which relates to a specific product mentioned in the article.  I’m more interested in a general concept of ground plane noise being transmitted upstream of a DAC, through the CPUs, to arrive at the timing sensitive endpoint - the DAC.

 

I agree that none of the upstream components, CPUs, processors, are themselves jitter or timing sensitive.  I’m asking why these upstream devices acting as conduits for ground plane noise are NOT a potential cause for jitter within that DAC.  Data arrives at the DAC intact as an electrical signal that relates to a ground plane.  The variation in that ground plane is influenced by whatever is upstream alters how the DAC processes the data through timing error within the DAC... not upstream.

Edited September 16, 2020 by Stereophilus

[pwstereo]

Why is the terminology “ground plane”?

It doesn’t seem right in this situation.

The Ethernet signal is on multiple twisted pairs.

[PCOWandre]

3 minutes ago, pwstereo said:

Why is the terminology “ground plane”?

Harder to put numbers to. Easy to measure noise on a signal line as a potential vs ground, or noise across a balanced pair. By just saying "ground plane noise", it becomes a "noise" with nowhere to put your scope probes. And both the "WSmartHub" and "EtherRegen" run from wall warts with no mains ground coupling to be a reference. 

 

Given all electronics will radiate a bit of noise, I'd say the best way to get a good measurement on a device like this would be to back the voltage off on the signal until it was right at the bottom of standard, assuming nobody will be connecting 50+ metre cables. Less signal, less noise.

[Guest rmpfyf]

1 hour ago, dbastin said:

So getting back to the topic of this thread, its not clear ro me if  @rmpfyf or anyone else provided a clear answer to my query which was along the lines of, what would be better than MikroTik?

 

Dale, it was in my post last night - good enterprise-grade switch > fibre > etherregen > very short CAT6 UTP lead > streamer.

 

So was the rationale, quite clearly. 

 

Most any second-hand enterprise-grade switch will do.