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.

jumia

This is my last post on this thread because I seem to be conversing with an EXPERT and there is no point in telling an EXPERT anything new.

I discovered this thing called GOOGLE and in 10 seconds a lot of info on packet loss on music streaming came up. Here is one that looks interesting. Though I have not tried it.

 

Activities like gaming and voice chat usually do not need much raw bandwidth, but they need prompt and reliable responses. These programs also do not usually resend information if it fails to get there, so if packets get lost in transmission, they are gone for good, which can also have a significant impact.

 

I wrote about the audible effects of packet loss on my home network about 6 months ago on this site. It happened when I had my ROON CORE PC behind a PowerLine network. The bandwidth of the PowerLine was not sufficient to handle the George Harrision's ALL THINGS MUST PASS album in h-res. I forgot the song but one song where he whistles caused the music to get distorted on my system.

When I moved the ROON CORE to the other side of the PowerLine network (to my normal Ethernet) the distortion goes away. This problem was reproduceable 100% of the time at an exact timestamp on the music. Now if streaming was not loosing packets then I would not have had the distortion.

This discussion was a slight divergence on whether to buy expensive cabling for streaming. 

@yyzsantabarbara  lol, you miss again. You really compared gaming and voice chat to Hires streaming? And you “program this stuff”.

where is your explanation on broadcast streaming?

 

since you use Roon, let me educate you : 

RAAT overview

https://help.roonlabs.com/portal/en/kb/articles/raat#Design_Goals

Release notes 1.3 detailing why they switched to TCP

 

 

so, you are simply wrong. 

@yyzsantabarbara man up now. You don’t know what you are talking about, it is as simple as that. But don’t take my word for it, ROON says so. At least admit it.

We have decades of experience building audio streaming protocols around UDP, and it has generally been our first choice, but we also know that both TCP and UDP, when implemented properly, are suitable for high-bandwidth, high-quality media streaming, so it was worth undertaking an exploration of “the other side” to see if there was actually a reason to consider switching.

After a series of experiments and prototypes, and a detailed exploration of both approaches, we found that we were able to extract more performance and reliability from TCP, so we took it to the next phase and started experimenting with TCP in our alpha environment a couple of months ago.

UDP is what I was referring to as BROADCAST.  I forgot the term but network BROADCAST messages in software are usually done via UDP. This type of message delivery is not guaranteed and can lose packets. So it looks like ROON  was using UDP and switched to TCP in June 2017. I was wrong thinking they still used UDP. However, that is just for ROON. 

The test I described previously shows me that ROON does not do a perfect stream today when something is limiting them on the network. The distortion I heard on a repeatable manner tells me that even with TCP something is going on that is giving a less than perfect stream to the DAC.

 

 

@yyzsantabarbara oh wow. You are special! Can’t even admit you have no idea what your are talking about after your vendor of choice throws it in your face.

 

UDP is not broadcast. It is a stateless L3 protocol. And no, it is not just Roon. You still don’t get it, if you lose a packer when you send a compressed stream, you can’t uncompressed that part of the stream at all. In addition, DRM requires at least digitally signed music, so, the entire song must be received in its entirety for it to work for downloads, and larger chucks of the stream that is digitally signed. The only thing you have proven is that your really have no clue, which I don’t blame you for, it is infinite more complex than a speaker cable, except that you keep saying you know something about it, which you absolutely  do not.
 

from Wikipedia “ The Internet Protocol Version 4 (IPv4), which is the primary networking protocol in use today on the Internet and all networks connected to it, supports broadcast, but the broadcast domain is the broadcasting host's subnet, which is typically small; there is no way to do an Internet-wide broadcast. ”

 

 

 

 

but hey, you “program this stuff”.