Is optical mostly a waste of time versus Ethernet?

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.

Packet loss sounds a lot like election fraud. Oh no

@yyzsantabarbara here you go again, John Swenson is NOT an audio streaming expert. That is a lie. 100% lie. Again, from UpTone’s website “John Swenson is widely known as a talented engineer, with decades of experience in silicon chip design” .

Stop lying. Please. John Swenson is a silicon chip designer, which is not even remotely close to audio streaming expert.

and your post never make any sense, if you lose a packet, how the hell can you regurgitate that lost packet, and the associated sounds in that packet?

However, the correct use of regurgitate is @yyzsantabarbara regurgitates things he reads on the Internet, meaning you just repeat statements out of context without understanding and comprehension of a topic you have claimed to program….

Regarding the streaming, TCP is incredibly reliable, and some of the topics that come into play are latency, window size, and yes, jitter. QOS has nothing to do with it as you can’t run QOS over the Internet (sure, you can tag your packets, and your internet provider will respectfully give you the finger and remove the tags, unless you pay for this, and then it is still only within that provider’s network and not the next network you need to traverse). It is all TCP.

and finally your comment about the 2k system. That is final sign of defeat, nothing factual backs up your claims, so now the listeners system isn’t resolving enough, spend more money. Well, I have a 45k system that I really enjoy, and I use enterprise grade networking equipment from juniper and extreme, and I certainly couldn’t hear a difference when I tried the Etherregen. Right now I am even running wifi to my NAD M50.2 due to a reno project, and no issues.

In process of more networking experiments, better modem with Broadcom vs Intel chip in old,  outboard power supply, Mikrotic  CCR1036 enterprise grade router.