Is optical mostly a waste of time versus Ethernet?

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.

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.

@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.

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.

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.