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

Optical greatly increased the SQ in my system.  Use two Cisco 2960's or Marika 220s cascaded by fiber w/ startech.com sfp's. You can add a shunt and lc filter to the power supply for even further improvements. 

Read the following on PACKET LOSS, Which can happen even on TCP streaming, contrary to the EXPERT opinion on this thread. This can happen when congestion of the network occurs. Which I said I can demonstrate 100% of the time with a low bandwidth setup of ROON Core.

 

 

John Swenson is someone who is an actual streaming audio expert and no one so far on this thread has shown they are an audio streaming EXPERT.

Great thing about Swenson ideas is that it is not very expensive to implement. If you have functioning ears and a decent setup you should easily hear the improvements from Swenson's setup for under $2K.

I personally have not got any expensive networking gear in my streaming chain. 

 

Reading something and understanding what it means in application are not the same. TCP ensures all packets are delivered including the logic to resend if lost.

 

 

Network transport protocols such as TCP provide endpoints with an easy way to ensure reliable delivery of packets so that individual applications don't need to implement the logic for this themselves. In the event of packet loss, the receiver asks for retransmission or the sender automatically resends any segments that have not been acknowledged.[3]: 242  Although TCP can recover from packet loss, retransmitting missing packets reduces the throughput of the connection as receivers wait for retransmissions and additional bandwidth is consumed by them.

Sure, packets can be resent byTCP. However, think about how streaming works. It is a continuous flow of music. You have packet loss and then what, the sender resends it so you will likely hear a regurgitation of the sound that was attempted before.

A buffering mechanism on the DAC may elevate some of these issues. Where do you do that buffering? The DAC would be the best choice but there are 100’s of DAC brands out there and likely no standard on buffering.

Now how about streaming internet radio? Resending packet sure would be interesting.

What seems to be common is that on guaranteed delivery TCP. When the network gets congested, The sender will throttle down so as to lower the congestion on the network and the packets will be dropped. This common practice is quantified as Quality of Service (QoS). That is a measure of how much packets were dropped on a network, including TCP.

Wow, all that just form reading.