Is optical mostly a waste of time versus Ethernet?

@fredrik222 So you are saying that dropped packets are resent in streaming? I do not think so. That is what I am referring to by BROADCAST. Maybe 1 level up from the TCP  level you started EXPERTING on.

Fibre Optical is the holy grail of streaming. I have 3 of the Sonore OpticalRendu's and they are fantastic at giving a very clean clear sound from your DAC. 

Putting a FMC in front of the OpticalRendu also improves the stream. However, I had 3 different brands in front of my OpticalRendu's and the only one standing is the EtherRegen. My Sonore OpticalModule is dead and a cheap FMC that was part of the Small Green Computer package is also dead.

For the 2 cases where the FMC's died I take the fibre optical directly from my network switch's. This does not sound as good as adding the FMC in front but it is not that much of a difference and I have moved on to listening to music.

 

So, here we go again, another thread about bunch of people applying pseudoscience audiophile terms to Ethernet. Nope. Ethernet does not work that way. Ethernet, along with the TCP/IP stack are several layers of error detection and in some layers error correction. If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.

So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard. 
 

but fiber for super short runs like 5ft is crazy waste of money. 

Are you saying that bits of music are going to be retransmitted in a stream if an error occurs. I doubt it. I believe a BROADCAST protocol is used instead of the REQUEST/RESPONSE I think you are alluding to. Yes, I program this stuff.

The reason to use Fibre in audio is not for transmission length specifically but for Fibre's ability to stop analog noise from traversing the cable and getting into your DAC. It is very easy to test and more importantly to HEAR the difference.

What I hear with Fibre over Ethernet is improved clarity, especially when using my Benchmark gear, AHB2 + LA4.

@fredrik222 

Did you forget to answer to my question of how streaming is done? Here is your statement.

If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.

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. 

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.

Here is a wiki article on packet loss. An explanation for my degraded ROON audio signal on that George Harrison song (the whistling part), when my ROON Core was behind a lower bandwidth PowerLine network is explained below.

The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messaging. Packet loss in a TCP connection is also used to avoid congestion and thus produces an intentionally reduced throughput for the connection.

I am not going to belabor the BROADCAST message type I brought up into the conversation. It is at a level higher in the OSI stack than is relevant for audio streaming. So my mistake on bringing it up in this audio discussion. I assumed that audio streams were UDP BROADCAST messages.

However, the crux of the point I was making was that network packets are being dropped in audio streaming. Contrary to what this self-proclaimed EXPERT is saying. The Wiki article indicates that even under the TCP protocol, packets can be dropped (intentionally).

My reproduceable test with the George Harrison song shows me how to mangle a song on ROON 100% of the time. This is an example of network congestion causing poor audio quality in streaming.

I believe the EXPERT was making fun of the people on here with functioning ears and also potentially more expensive network cabling and routers et al, than the EXPERT themselves use.

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. 

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.

@fredrik222 You are one cat that has selective comprehension. Who the heck was talking about " QOS over the Internet". I was talking about on the home network as I clearly stated in my reproduceable test of how to make a ROON stream distort the sound 100% of the time.

I certainly couldn’t hear a difference when I tried the Etherregen.

Each of us hears differently and also tests these things differently. When I tried the ER on a $10K streaming Integrated amp it had no sonic benefit to my system. When I tried it in reverse order (B > A) using Swenson’s guidance with fibre optical I was able to easily hear an improvement. That is the fibre setup improved even more. Swenson does not actually state to use a ER, for this use case. He suggested a FMC but I only had the ER handy so I used it B > A.

However, since you did not hear any improvement then no one will. Guys. like you are entertaining. I am bored now with you.

A $45K system is great for the economy. I am sure you made some people happy buying that gear (hopefully yourself too). However, the last thing I would do is to use the price of audio gear as some representation of quality.

Anyways, for the folks that are curious I have provided enough links above for you all to do you own deep dive. One of the reasons, I found some of these issues on ROON is because I listen to just under 200 hours a month on ROON (there is a total on one of the ROON views). You think streaming problems do not crop up during this time.