Is optical mostly a waste of time versus Ethernet?
The only value I see with a fiber optical cable is if you have a long long run.
All the noise coming into an optical fiber is preserved and comes out the other side. I guess there is a value in not creating more noise while it is traveling through the optical cable. But if it's a short run of two Feet then is it really worth it. Seems a well shielded Ethernet cable would do just as fine without all the hassle of converting to optical which is a pain in the ass.
I always thought there was value with optical but it seems they're really may not be. Maybe I'm wrong. It seems a switch likely produces a lot of noise and inserting an audio grade switch is very prudent and going optical really doesn't solve switch noise problem. The benefit of re-clocking offered by a decent switch to clean up the signal is worthwhile.
@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.
|
@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.
|
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. |
