Is optical mostly a waste of time versus Ethernet?

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

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

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