Is optical mostly a waste of time versus Ethernet?

@sns thats what it is about right? It is a hobby, so have fun with it! 

We shall see. Already tried audiophile switch, sound quality diminished from my netgear wif/router powered by lps.

In any case, having fun learning about myriad configuration options with the Mikrotic.

@sns  the point why I am recommending enterprise grade equipment is due to consistent and predictable performance. It’s been tested over and over again and the support from the company and reputation of the company is behind it.

but like you said, you don’t need that typically for home use, and your microtik is fine, a bit lower throughput that I would want with 16 ports and only 16gbit throughput, which means it can’t support all ports at full speed, as that requires 32gbit throughput (duplex, each port can transfer 1gbit in each direction). These specs matter if you want to minimize jitter and latency.  

Another concern I have with microtik is the cpu vs asic/fpgu. Also doesn’t promote consistent latency and jitter. And then it is shared data and control plane, which means if you are doing configuration changes, it could impact performance. 
 

anyway, there is a lot to this topic, but in most cases a netgear from bestbuy is fine. 

Isn't low line Mikrotik, this ccr1036, designed for business environment  has much capability IMO. Not saying top of line, but what more does one need in home environment. This is all in service to audio and my curiosity, not to providing network to some large enterprise.

If you want more details on enterprise grade, Forbes defines it here: 

@sns  no, that is not accurate. You still can expect incremental improvements of mature technologies, and I assume a lot more metadata will be integrated in the future to augment the listening experience.

Certainly intentions to be malicious in any posts, but if you can’t call out people on BS and at least try to have a fact based discussion, what is the point?

I did miss that you had acquire a microtik, although, I wouldn’t call that enterprise. Better than consumer, for sure, so a step in the right direction. So that begs to question, what is “enterprise” grade? Gartner defines it as follows: “Enterprise-grade describes products that integrate into an infrastructure with a minimum of complexity and offer transparent proxy support.” 

so what does that mean? Mainly that the products are not designed to operate a single unit, like an access point or switch for a consumer, rather a part of a total solution, solving more than one particular issue. And with the appropriate support structure for this. 

@fredrik222 Okay, audiophile streaming is mature technology, don't expect further innovations. Is that an accurate statement?

Quite obvious you don't have patience for 'ignorant' people, in fact your additional comment as to the stupidity of people in regard to things political exposes level of malice also exposed in this thread.

As for expertise, a lot of us don't have expertise in many fields, not enough hours in the day.

Issue here is the usual overgeneralization and categorization of entire cohorts of people. Plenty on this forum ignorant about many facets of this hobby, but most are trying to educate themselves both through other's expertise and experience. You assume I'm not willing to educate myself, I suspect your emotions coloring your reading comprehension skills when you completely missed my post as to the purchase of Mikrotik enterprise grade router. In fact I'm at this very moment in steep learning curve getting this thing configured. I may never totally understand all the technicalities of networking, but at least I'm wiling to experience a wide variety of equipment and protocols involved with audiophile streaming.

@sns there you go, that is my point. You made a statement that is wholly inaccurate. I gave you information to educate yourself, and you continued down the same path.

how you perceive me is up to you, I just have no patience for ignorant people, especially people who chose to be ignorant. While that is not popular in today’s political climate where being ignorant and stupid is cool and everyone has an equal voice on all topics, I don’t subscribe to this, rather, I find it appalling.

I don’t know a lot about a lot of the topics discussed on this forum, but like I have said, I know more than anyone on this forum about this particular topic. Or at least until proven that it is not so. I am not apologizing for this, nor do I have to play nice with people who argue without any knowledge or sources, or regurgitate things from a webpage that they don’t understand, or outright lie.

@fredrik222 You certainly make many assumptions about me! I mention audiophile streaming being an immature technology and you go off on tangent about me being close minded, ignorant.

You seem to be one contentious person, you've ridiculed a number of people in this thread, this  not constructive in a forum where members are endeavoring to learn from others and listen to their experiences.

Constructive posts are those with positive bent, educating without belittling. You sir, cannot be a valued resource until you learn reasonable etiquette in dealing with others. Learn to strain out the narcissistic bit, gets old extremely fast.

I encourage anyone to learn, and as you learn, you understanding will evolve. For pro audio, which have been using high quality streaming for 20+ years, there are two standards that most seems to use, AES67 and SMPTE ST 210. Now, I am not an expert at either protocol, but I have designed and built networks to support these protocols across the US and across the Atlantic.

Companies like Ravenna puts both of these into practice, and provides a wealth of information, and they don’t use products like Etherregen, but if you really really want to twist it, they do use optical for SQ, since the distances involved far exceeds copper Ethernet capability, so if you want to twist it you could say that pro audio uses optical to provide high resolution audio and improve SQ over Ethernet copper, since copper would not transmit anything at all.

but for short runs, all regular Ethernet.

@jumia no humor, just harsh reality. @sns keeps mentioning that “we” don’t know anything streaming yet and that it is a immature technology. That is a lie.

why call it a lie instead of no true? Because I have given him links to educate himself, especially on the pro audio applications and protocols, but he insists. So his statements are then simply a deliberate lie. Why did I say it is beyond him? Well, obviously, he either can’t understand protocols used, either in consumer audio or pro audio like Ravenna, or he desperately want to hold on to his limited world view, which then, clearly, the truth is far beyond him.

Fredrik222,

Hey I just read your last post —— was this supposed to be humorous?  It comes across especially harsh.  Sometimes attempts at humor don't go very well.  Keep practicing you'll get there soon.

@sns no, not at all. It is a mature technology far beyond your comprehension. It is used in pro audio and pro video daily. You don’t understand, along with others on this forum, but calling it immature is just a spectacular show of your ignorance. 
 

you don’t understand it, but it is used daily at level far beyond your reach. 

I would advise you to open your eyes, read up on the topic, I have given you numerous sources to educate yourself, yet you chose to be ignorant. 

I've experienced enough streaming components, and observed so many variations in streaming solutions others report having good experiences with to write off any particular component or collection of components. I do believe we'll get to a point where simpler is better becomes a de facto standard, optimizing components by utilizing best technology available within each is key to getting there. Streaming still relatively immature technology, expect great number of innovations in coming years.

Uptone is of questionable value. All about positive reinforcement. I bought one and really haven't seen any value in it at all.

no one understands what's going on inside this thing. It's all gibberish. Someone has created a lot of circuitry within this Metal box they created and they're selling it.

And then you hear that crappy Power cord they sell with it. Horrifying. They want you to buy a power supply upgrade after spending $600 on a switch. 
 

And then they say well you can't use more than one item on it because it contaminates the signal.  So don't dare to share it with anything else on your net work.

At least they could've furnished a longer power cord a better quality.  Right now it's just a pain in the neck to deal with

@yyzsantabarbara  EtherRegen doesn't support QOS, so there is that. Need managed switches for that, and EtherRegen is not managed. And while you can configure a lot, most QOS configuration do not limit or prioritize anything until you hit the defined congestion threshold.  However, EtherRegen, if you have a congested network, by design, can cause issues, since you have "A" ports that are gigabit, and the "B" port that is supposed to go your streamer/dac, which is 100Mbps. If you are pushing over 100Mbps on the "A" side, and for some reason push it to the "B" side, you will introduce packet drops. It is even possible that the EtherRegen will flood the "B" side with everything going on on the "A" side. UpTone does not give any type of specifications for this, or any other specifications at all, only "ultra low jitter" and "ultra low noise" without and numbers. 

What we do know about the UpTone is that they use cheap components according to their own pictures of the circuit board.

Did you ever think about this in a objective manner?

1) Uptone provides 0 specifications

2) There is no measurable improvement to their claims

3) There is no theoretical improvement to their claims 

4) They use cheap components 

5) Some people hear a different, but others do not. 

Maybe there is a confirmation bias involved, maybe?'

You are the one who brought in the money, I get it that you feel stupid when you thought I had a $500 marantz receiver from BestBuy with a Klipsch $300 bookshelf pair, but if you want to argue that Classe Audio for Pre/Power is not good quality, you are in a league of your own, and will really feel stupid. 

@fredrik222 You are one cat that has selective comprehension. Who the heck was talking about " QOS over the Internet". I was talking about on the home network as I clearly stated in my reproduceable test of how to make a ROON stream distort the sound 100% of the time.

I certainly couldn’t hear a difference when I tried the Etherregen.

Each of us hears differently and also tests these things differently. When I tried the ER on a $10K streaming Integrated amp it had no sonic benefit to my system. When I tried it in reverse order (B > A) using Swenson’s guidance with fibre optical I was able to easily hear an improvement. That is the fibre setup improved even more. Swenson does not actually state to use a ER, for this use case. He suggested a FMC but I only had the ER handy so I used it B > A.

However, since you did not hear any improvement then no one will. Guys. like you are entertaining. I am bored now with you.

A $45K system is great for the economy. I am sure you made some people happy buying that gear (hopefully yourself too). However, the last thing I would do is to use the price of audio gear as some representation of quality.

Anyways, for the folks that are curious I have provided enough links above for you all to do you own deep dive. One of the reasons, I found some of these issues on ROON is because I listen to just under 200 hours a month on ROON (there is a total on one of the ROON views). You think streaming problems do not crop up during this time.

In process of more networking experiments, better modem with Broadcom vs Intel chip in old,  outboard power supply, Mikrotic  CCR1036 enterprise grade router.

@yyzsantabarbara here you go again, John Swenson is NOT an audio streaming expert. That is a lie. 100% lie. Again, from UpTone’s website “John Swenson is widely known as a talented engineer, with decades of experience in silicon chip design” .

Stop lying. Please. John Swenson is a silicon chip designer, which is not even remotely close to audio streaming expert.

and your post never make any sense, if you lose a packet, how the hell can you regurgitate that lost packet, and the associated sounds in that packet?

However, the correct use of regurgitate is @yyzsantabarbara regurgitates things he reads on the Internet, meaning you just repeat statements out of context without understanding and comprehension of a topic you have claimed to program….

Regarding the streaming, TCP is incredibly reliable, and some of the topics that come into play are latency, window size, and yes, jitter. QOS has nothing to do with it as you can’t run QOS over the Internet (sure, you can tag your packets, and your internet provider will respectfully give you the finger and remove the tags, unless you pay for this, and then it is still only within that provider’s network and not the next network you need to traverse). It is all TCP.

and finally your comment about the 2k system. That is final sign of defeat, nothing factual backs up your claims, so now the listeners system isn’t resolving enough, spend more money. Well, I have a 45k system that I really enjoy, and I use enterprise grade networking equipment from juniper and extreme, and I certainly couldn’t hear a difference when I tried the Etherregen. Right now I am even running wifi to my NAD M50.2 due to a reno project, and no issues.

Packet loss sounds a lot like election fraud. Oh no

Sure, packets can be resent byTCP. However, think about how streaming works. It is a continuous flow of music. You have packet loss and then what, the sender resends it so you will likely hear a regurgitation of the sound that was attempted before.

A buffering mechanism on the DAC may elevate some of these issues. Where do you do that buffering? The DAC would be the best choice but there are 100’s of DAC brands out there and likely no standard on buffering.

Now how about streaming internet radio? Resending packet sure would be interesting.

What seems to be common is that on guaranteed delivery TCP. When the network gets congested, The sender will throttle down so as to lower the congestion on the network and the packets will be dropped. This common practice is quantified as Quality of Service (QoS). That is a measure of how much packets were dropped on a network, including TCP.

Wow, all that just form reading.

Reading something and understanding what it means in application are not the same. TCP ensures all packets are delivered including the logic to resend if lost.

Network transport protocols such as TCP provide endpoints with an easy way to ensure reliable delivery of packets so that individual applications don't need to implement the logic for this themselves. In the event of packet loss, the receiver asks for retransmission or the sender automatically resends any segments that have not been acknowledged.^[3]: 242 Although TCP can recover from packet loss, retransmitting missing packets reduces the throughput of the connection as receivers wait for retransmissions and additional bandwidth is consumed by them.

Read the following on PACKET LOSS, Which can happen even on TCP streaming, contrary to the EXPERT opinion on this thread. This can happen when congestion of the network occurs. Which I said I can demonstrate 100% of the time with a low bandwidth setup of ROON Core.

John Swenson is someone who is an actual streaming audio expert and no one so far on this thread has shown they are an audio streaming EXPERT.

Great thing about Swenson ideas is that it is not very expensive to implement. If you have functioning ears and a decent setup you should easily hear the improvements from Swenson's setup for under $2K.

I personally have not got any expensive networking gear in my streaming chain. 

Optical greatly increased the SQ in my system.  Use two Cisco 2960's or Marika 220s cascaded by fiber w/ startech.com sfp's. You can add a shunt and lc filter to the power supply for even further improvements. 

If using Roon none. If using and of the streaming services which are all TCP based with buffering and retry, none. If using something locally like HEOS, DLNA, etc. not sure all would need to be evaluated (on paper). I remember not long ago seeing a test with JRiver (not sure what protocol) and there were lost packets. That’s not a JRiver issue, just what protocol was used for that connection. In my local network, I have done tests wired and lost no packets over 30+ minutes. WiFi you lose packets but I don’t think anyone would use a protocol with WiFi that loses packets.

Lots of talk about packet loss which doesn’t sound good. How many packets are we talking about versus the actual volume of packets that arrive every second.

@sns and others, like I said previously, John and UpTone are not wrong when they say there can be leaks via Ethernet that would interfere with internals of a streamer or other component. This used to a huge issue in the 90s for computers, and it has continued with cheap components that have found themselves into non computer related devices like audio equipment. But most networking cards today don’t have these issues, even the really cheap ones. And I am hoping that streamers and other components that costs thousands of dollars like my NAD M50.2 don’t use really crappy components, but it wouldn’t surprise me if they did, after all, they are audio engineers,  not networking experts. 
 

But, and more troubling for John and UpTone, you can measure this very easily, and UpTone Etherregen does not eliminate any of this at all.

@sns John is not a networking expert or anything networking. He is, as he says himself, a silicon chip designer.
 

”John Swenson is widely known as a talented engineer, with decades of experience in silicon chip design (he was a senior project lead at a major integrated circuit firm for 30 years).”

There are networking 'experts', and those who've integrated that knowledge with an understanding of how it relates to and affects audio streaming sound quality. People like John Swenson of Uptone Audio, and some others who can be found at audiophilestyle forum, these are the 'experts' I rely on for guidance in streaming.

Add to this expertise, a knowledge base formed from those with practical experience, those with open minds who've tried a variety of audiophile focused streaming products.

Between these two cohorts of expertise, one finds guidance on how various products work and their efficacy. And then we have the final 'expert', if one trusts their sensory perceptions, they become the final arbiter of what is effective and not in their unique streaming setup.

@fredrik222 

I appreciate you AND @theaudiomaniac for sharing your knowledge. The chest bumping not so much. Unfortunately, there is a little more of that on Audiogon these days and I know I've done my part to perpetuate it from time to time. Have a terrific day.

@ghasley of course I could be nicer, but is that how you react when someone says you don’t know what you are talking about and then just makes stuff up?

but you are correct. I can of course be nicer, and you are also right that I should be nicer. 

@fredrik222

If I were the moderator I would remind you that certain standards of decorum and relevance should apply to posting here. I might even imply that your approach and apparent gloating was churlish or prickly at best. Since I am not the moderator, I will refrain.

You’ve made your point, most here could give a shyt how the data arrives, we accept it because we have few options to the contrary depending on cable providers. What we choose to do to the data once it arrives to our doorstep is where this conversation initiated. But again, I’m not the moderator so it isn’t my place to tell you any of the above.

@theaudiomaniac  you are saying you don’t have any more knowledge on the topic  and therefore no one else does either. Good argument. like I have stated before, I know more about the topic that anyone on this forum, including yourself, until proven that it is not so.
 

one thing you certainly did not was to dispute any absolutes, in fact you, yourself said that the forum is anti Audioscience…
 

What you don’t call a reliability wrapper is up to you, UDP specifically states it leaves reliability to the higher level protocols. VoIP measures it for  quality, gaming and gamers are obsessed with their “ping” there are controls. Neither requires that every packet is received, but have reliability safeguards to ensure a minimum level of performance.
 

And you are wrong when you say it is a wrapper around UDP, it is on top of UDP. Also wrong when you say the purpose of a reliability wrapper is to manipulate the data, it is literally the opposite, to ensure data arrives intact. How much data? well that is up to each individual application accepted performance level. 
 

and finally, it is just flat out a lie that Roon did not support Tidal/Quboz before they switched to TCP. They most certainly did, and it is easily verifiable too. Which means they had to have a reliability wrapper on top of UDP to ensure DRM, proving you wrong again. 
 

in summary @theaudiomaniac , yes, you do have limited knowledge, and can’t even bother to do research. We can agree there.

@theaudiomaniac thanks for the reply. Indeed, there are alot of absolutes and alot of exceptions. I hear material sound quality differences and I am skeptical by nature. But what do I know, I enjoy tube amplification but my system is a digital only source. I hear differences in cable and it isn't subtle so I'm probably not going to be invited by Amir to opine on much. All the best...

Yawn....no need to measure...they are both the same length.

@ghasley 

There is a potential mechanism for noise transfer and this would be system dependent. I have my doubts, but the mechanism exists. An argument could be made about the impact of that noise on jitter in a clock on the DAC device. I find that argument unreliable and not supported by available measurements. Similarly, I find the argument about jitter in the Ethernet as an issue unreliable. All these things would be too easy to demonstrate. My spidey sense goes off then easily demonstrated things are not.  Been in this hobby long enough that I don't trust what I thought I heard any more, proven myself wrong too many times. I am not about to start taking other people's words for it. Used to do that. Poorer for it.

I won’t derail this thread any further @fredrik222, but I think I have posted enough information to clearly illustrate that the absolutes you discuss are not. Roon, as a server, specifically does not support DRM. It has very limited support, and only supported services that use DRM (Tidal/Qoboz) after their change to TCP. Prior to TCP, it was UDP and I will go back to my statement that you do not know if they guaranteed delivery. If I had to guess, I would say they did not. I wonder what other local streaming implementations are still using UDP and susceptible to packet loss? I have no worries about web-based, they are TCP based, but for local, I would want to be verifying what is being used is guaranteed delivery before assuming it is.

A packet loss indicator or VOIP quality indicator is not really a wrapper as it is not implementing any manipulation of the underlying data (typically), though people seem to call almost anything a wrapper if it interacts with the data, even if it does not manipulate it.

Where reliability wrappers are used in gaming platforms is custom implementations for ensuring controls information is transmitted, i.e. press a key, move a mouse, etc. The small amount of data does not lend itself well to TCP, but you need to ensure the data gets there. Gaming platforms write a custom wrapper around UDP (just like UDP is essentially a wrapper itself) to accomplish this. This does not make sense for streaming where the data is relatively large, the latency unimportant, and a suitable method already existing.

You can respond, but I will not. I would like to respect the topic of the thread. I don't doubt you have some networking experience, but I also doubt that you lack application specific knowledge in this area.

@theaudiomaniac you specially called me out. My posts are accurate, networking is as close to absolutes as you can come.

Your comment is more or less exactly what I said…

As for wrappers around UDP, most applications do build some sort of reliability wrapper around it. In the case of Roon, they specially call out the need to support DRM, which requires reliable transmission. 
Other applications like gaming have indicators of packet loss, which is a reliability wrapper, if you didn’t, the game would either crash or just hang if you lost connection somewhere. 
VoIP also have call quality indicators, another form of reliability wrapper. So, it is more common than not to use UDP and a reliability wrapper. 
 

You are both very knowledgeable and I'm grateful those standards mentioned aren't my decision to implement. The OP asked if there were solutions to improve noise, clocking, jitter, etc and were they beneficial. Some Audiogon members report improvements, others not so much. Who is right, maybe everyone. Each system is different, each environment is different.

The OP is an adult and can choose to check these out or not.

Or they switched because they were not providing high level correction of lost packets, realized it was an issue in some networks, and went the TCP route to fix it since most home networks today have more than enough bandwidth unlike when they developed their product.I don't know the answer. I don't think you do either. Roon networking is for local connectivity, though it does provide management and access for external services.  Most do not put a wrapper around UDP to guarantee transport. If you are going to do that, you go TCP. For UDP, any number of feed-forward and error correction schemes are used for media to provide coverage when packets are lost and some minor retransmit schemes have been used where low latency can be maintained, but full guaranteed delivery makes little sense with UDP when TCP exists.

If you felt called out, perhaps consider not making absolute statements that are incorrect nor holding yourself up as absolute.

@theaudiomaniac so, you called me out. What is wrong in any of my posts?

to your posts, I would add while UDP does not provide reliability at the transport layer, it leaves that to the higher level protocols. Which is huge headache, and probably why Roon ultimately switched to TCP.

Almost forget what this was about.  Ethernet ports are transformer isolated. They won't pass low frequency noise. They can pass high frequency noise, but its a transformer. It will reject most common mode noise. How hard can it be to isolate that part of the circuit from the DAC and analog?  Seems every piece of electronic test equipment has an Ethernet port today. They don't seem worried.  Someone mentioned jitter. I know this crowd is anti Audioscience, but tests are tests emotions aside. Jitter shows up as distortion. Tests I have read have been laptops and basic router/switches into DACs. I don't seen any added distortion from ethernet.

I see a lot of expensive Cat-6/7 cables. Those are shielded. The shields are connected at both ends. That does sound like a recipe for a ground loop that did not exist before.

My my my. Does one jump into the hornets nest on their first post?

Concerning the "expert", I very much have doubts about their expertise. When you have been around true experts, you notice things. Clear, concise, few necessary references, talk in pros and cons, specifics, etc.  I see some of that, but not a lot. Experts rarely arbitrarily say they are the best. They let their words speak for themselves.

Audio over an IP network needs to be broken down into at least 3 types.  Real-time audio such as VOIP, conferencing, screen sharing, even in large real time studio applications. Compressed, streamed, and buffered music. Uncompressed, streamed and buffered music.

Different protocols are used for real time audio versus streamed and buffered. With real time audio, packets can be permanently lost. This is acceptable in the protocol as latency is more important than anything.

With streamed and buffered audio, which is what streaming services would fall into, lost packets will be re-transmitted with the net result being all packets, except very rare circumstances, will be delivered to the receiving end. I can't speak for the internals off all the apps/Win/OSX programs out there, but I have seen comparisons showing streamed and CD were the same. I would expect those streaming services in conjunction with their receiving programs use a variety of error correction and re-transmit techniques to minimize overall bandwidth where possible.  With compressed, and I don't mean FLAC, the service does have the option of dropping information to reduce bandwidth.

Do IP networks drop packets to manage bandwidth? Absolutely. That does not mean they are never delivered though. That just means that particular sent packet was not delivered. It can be resent till it gets through.

It is guaranteed that the protocol between your local server and end-point is using a fully recoverable protocol, i.e. not total packet loss?  If the product is using a standard protocol like DLNA and approved you can be sure of how it behaves. I am sure our expert can chime in on that. If proprietary, no comment.

UDP has no guaranteed delivery mechanism. TCP does. If you are using a TCP protocol, there is inherent functions built in to guarantee delivery no matter what the application does. UDP does not guarantee that. TCP allow setting up secure connections. UDP does not. You can make your own conclusions about paid streaming services and use (obviously TCP). UDP does support broadcast messaging, but normally only used for discovery.

We know that TCP is used by all major streaming services, and that pretty much guarantees in most cases all packets arriving, with application layer taking care of the rest using buffering.  What is happening on your local network?  Could it be UDP? Maybe.  I do know in my own network, I have pretty no losses, so it really does not matter to me.

@jumia 

You are correct, better clocking and jitter control are equally as important. Once again, its one of those things in the hobby that once you hear it, or better stated, once you "don't hear" the negative effects of noise/clocking/jitter is when there are some rather obvious aha moments.

These debates don't really change the thinking of either "camp". Those who have experienced positive effects are considered converts or ill-informed (depending on who is doing the considering). Those who are certain there is nothing to be gained from the effort, gain nothing by not going through the effort. Hey, maybe there is nothing to solve in their system. I do, respectfully, disagree with @fredrik222 because I have experienced the positive effects of certain cables, switches, etc and I have also experienced no effect from some while others actually adversely impact the quality of the sound. It doesn't make anyone right or wrong, it does however make you think a little about how so many rational people can be on opposite sides of topic.

​​​​​​@fredrik222 is right, maybe "my budget" system required some assistance whereas his system is fully fleshed out. Who knows? It would help us all get better performance if people like @fredrik222 would list his gear. I dont typically list mine because it is always changing slightly and I dont want to embarrass myself.

Everyone is talking about noise which has merit, but what about clocking and jitter. Seems this is the most important thing relating to clarity no one talks about.  faster and more precise clocking chips which seem to have Great impact on sonic performance.  Dacs do their own reclockin but when what they get is in better shape it really helps I guess.

So does anybody know anything about clocking? And also Basic network switches allow the data gate to remain open at a constant rate, ie 100 mbs.  Versus an audio file switch which better controls for the lower dataflow needs which is closer to 5 to 10 Mbs, which limits the transfer of noise I guess. Not sure how this exactly happens.

How could any of this make a difference but it does to those who have experimented.

OTOH, that is not true for everyone.  I have tried a number of these things with results being so subtle as to question whether there is really a difference.  It's not that I summarily dismiss the possibility that this stuff can make a sonic difference, but, at least in my room with my equipment, none of this stuff so far has made an easily identifiable change or improvement. 

@ghasley there you are wrong. Optimal audio quality over a IP network is fully understood by people like me. Do you again believe the banking is comprised daily? Or do you think super hi res simulcast concerts don’t know what they are doing? Look at Ravenna for instance.

The only potential issue is that noise from a short run Ethernet screws up a horribly implemented networking card, and if you remove that noise you could notice a difference. That premise means your super high end streamers use crap components, and that something like Etherregen removes noise. Well, noise is measurable  and it doesn’t remove any noise at all. While I am sure that lots of manufacturers use bad components, but even todays bad components, are very good at handling bad noise environments. 
 

@fredrik222

Thank you for the thoughtful reply. What you explain clearly in layman’s terms is appreciated. There are alot here on Audiogon who may be proficient at what we are proficient at while enjoying the audio hobby which is admittedly not our day job.

With that said, there is still alot that we collectively don’t fully understand when it comes to optimal sound quality over ethernet. Obviously we are only dealing with “the last few feet”, much like we do with power delivery, and no two home systems/rooms/environments are identical. How much noise are we trying to reduce/eliminate and how much noise do we accidentally introduce to the digital chain?

When it comes to ethernet cables in general, ethernet switches and noise, it shouldn’t make a material difference, said my right brain for many years. In fact, even if it made a material difference was it always a positive or a negative difference and if so/not, why?

I heard a positive difference when I inserted the Ether Regen into my chain. I heard a further positive improvement when I inserted Audioquest ethernet cables in place of those provided by my IT expert. While he may not be at your level, I’ve never had a financial transaction fail to successfully complete with those cables but I clearly heard a positive difference. Now, with my Network Acoustics switch, further sonic improvements were clearly heard. Same goes for the Network Acoustics Muon ethernet cable and Muon filter. Even though you may not believe it could possibly make such a positive difference, could I respectfully ask that you suspend disbelief for a moment and help me understand why it would/could?

Could it be the difference between the requirement for a steady stream vs the obvious advantages associated with simply arriving at the identical sum on both ends of a financial transaction? For instance, if the stream had a 20ms silent lag per second, that wouldnt affect a financial transaction but it likely would with streamed music. I don’t deny that its comparing apples to oranges but I know what I am hearing is vastly improved over an already highly satisfactory musical presentation. The conundrum for most here is that the logical side ouf our brain agrees completely with you. How could any of this make a difference but it does to those who have experimented.

@ddafoe i did. Show me another person here that knows more and I will readily admit so, however, out of the thousands of posts on this topic, my conclusion is firm. 

@ghasley it is very possible for noise interfere with Ethernet, for sure. The point is, Ethernet is built to withstand it, and that’s why I said a safe bet for a Ethernet run without special conduits, etc. is 100 ft for residential applications. See below the max distance which in some cases is dependent on the speed, however, as a general statement, no benefit to deliberately slow down.

going back interference, the protocol Ethernet have error checking, each frame transmitted includes a checksum to make sure nothing corrupted (changed) during transmission, see below. And this is just one layer. Every layer have these checksums, and the actual application layers deal with compression and digitally signed content (DRM). So if you in anyway, modify the payload, all of these layers will fail all their checks, and it will be discarded and retransmitted. In reality, as soon as one layer detects an issue it is discarded and never goes further.

now, can noise travel via the Ethernet cable into the device itself and cause issues, sure, but that would mean a very poorly network card implementation in the device.

https://www.tripplite.com/products/ethernet-cable-types?utm_term=&utm_campaign=a.Cables+-+Panels,+Jacks+%26+Hardware&utm_source=adwords&utm_medium=ppc&hsa_src=g&hsa_ad=522769106538&hsa_tgt=dsa-1274206709011&hsa_mt=&hsa_ver=3&hsa_acc=4932208510&hsa_kw=&hsa_grp=121359314526&hsa_cam=696012424&hsa_net=adwords&gclid=Cj0KCQjwxveXBhDDARIsAI0Q0x1eE6NPdYOyoq_munQUKOqbWS7kYPopMyKZdsy4k7xHq-qWBnGZPWEaAvijEALw_wcB

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