Is optical mostly a waste of time versus Ethernet?

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.

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

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.

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