You have too much network bandwidth!!


As I was fiddling around with my Roon streamer, putting the finishing touches on the network configuration I started monitoring the network throughput of the end point. With a stereo 196 kHz/32 bit audio signal it uses about 1.5 Mbits/second of bandwidth.  

This means a typical 1 GigE could support about 70 simultaneous high resolution audio streams.  Even an old-school 100 Mbit network could handle 9 of them. 

My point really is just that chances are good your home network already has much more bandwidth than you need for high resolution audio. 

erik_squires

@richardbrand 

The FLAC discussion was base on a post saying PCM doesn't have to be compressed and implied it was better than compressed files for music.  I was pointing out the CPU even at the maximum compress of FLAC is so small as to not be a real consideration.

Buffering is a completely different topic and has been a discussion about whether it's good or bad.   The providers have already made this decision for us, so in my view it's a non-factor as to whether small bits of data like a music file is being harmed by latency and error correction in the IP protocol.   The short answer is "it's not".  So I agree with you on this point.  However, there is train of thought in the audiophile community that think like error correction is bad, so you must buy audiophile switches and ensure no magnetism gets close to your gear, and for the most part audiophile switches are  just a chinese house brand switches with a different paint job.

VOIP as you mention is sensitive to latency, but particularly jitter but that's a different issue entirely.  Downloading a FLAC file even 1M (which is extremely large for a flac file) will take approximately 1 second to download.

Video is an interesting topic;  I think many technical people believe it uses UDP, but in fact most video streaming is done using TCP because it gets priority on the net and it doesn't have to switch ports when it reaches the destination.  There are other protocols for video but in practice those have not been used by the majority of video providers like Apple or Netflix and have fallen by the wayside.

Apologies for the long response.

@tomrk 

there is train of thought in the audiophile community that think like error correction is bad

Wish they could understand that all digital is realised by analogue signals and they can go bad!  What distinguishes digital done correctly is that errors can be detected and corrected.  In most cases, the exact original data can be preserved. Detection and correction require data buffers - the bigger the better.

Those using I2S should ponder this, because I2S does not provide any error detection or correction whatsoever.  I sense mis-information from vested commercial interests, who do not want to pay HDMI licence fees, is at play. 

On the other hand, too much error correction would indicate that something analogue is flaky, somewhere, and should be fixed.

Video is an interesting topic;  I think many technical people believe it uses UDP, but in fact most video streaming is done using TCP because it gets priority on the net and it doesn't have to switch ports when it reaches the destination

On the contrary, UDP gets prioritised over TCP. because TCP is not considered time-sensitive.  Ports are just a logical construct in Internet Protocol (IP) that tell the receiver what "app" to use to handle each packet.  TCP and UDP both run over IP

ChatGPT says:

TCP and UDP are both transport layer protocols that send data between devices, but they prioritize different things: TCP is connection-oriented and reliable, while UDP is connectionless and fast. TCP ensures data is delivered accurately and in order, making it suitable for applications like file transfers and web browsing, whereas UDP is used for speed-sensitive applications like video streaming and online gaming where occasional packet loss is acceptable

@richardbrand 

On the TCP vs UDP.  

Netflix uses TCP—not UDP—for video streaming because TCP provides reliable, ordered, and error-checked delivery, which aligns with Netflix’s strategy of pre-buffering and adaptive bitrate streaming.
🔍 Why Netflix Chooses TCP Over UDP
While UDP is faster and often used for real-time applications like gaming or video conferencing, Netflix’s streaming model prioritizes reliability and quality over low latency. Here’s why TCP is a better fit:
✅ Reliability and Error Correction
•     TCP guarantees delivery of all data packets in the correct order.
•     If a packet is lost or corrupted, TCP retransmits it automatically.
•     This ensures high video quality and prevents glitches or missing frames.
📦 Pre-buffering and Adaptive Streaming
•     Netflix pre-buffers content, meaning it downloads chunks ahead of playback.
•     TCP’s congestion control and flow management help optimize bandwidth and adjust video quality based on network conditions.
•     This reduces buffering and ensures a smoother experience, even on fluctuating connections.
🔐 Security and Monitoring
•     TCP supports HTTPS, which Netflix uses to encrypt and secure video streams.
•     It also allows Netflix to monitor bandwidth and adapt streaming rates dynamically.
🚫 Why Not UDP?
•     UDP is connectionless and doesn’t guarantee delivery or order.

On AppleTV:

📦 TCP  – for Reliable Streaming
Apple TV uses TCP for most of its core streaming and communication functions:
•     Port 80 (HTTP) and 443 (HTTPS): For secure streaming from Apple TV+, iTunes, and other services.
•     Port 3689 (TCP): For iTunes Library Sharing.
•     Port 123 (TCP): For time synchronization with Apple’s time servers.
•     Port 7000 (TCP): For AirPlay streaming data (especially screen mirroring).
•     Ports 5000–5001 (TCP): AirPlay control channels.
TCP ensures reliable, ordered delivery of video and metadata, which is critical for high-quality streaming and DRM-protected content.

📡 UDP (User Datagram Protocol) – for Discovery and Low-Latency Tasks
Apple TV also uses UDP for tasks that benefit from speed over reliability:
•     Port 5353 (UDP): For Bonjour/mDNS service discovery (e.g., finding AirPlay devices).
•     Port 123 (UDP): For NTP (Network Time Protocol) sync.
•     Port 554 (UDP/TCP): For RTSP (Real-Time Streaming Protocol), used in some AirPlay scenarios.

 

Like I said, most technical people believe UDP is what is being used by netflix and apple, but it’s actually TCP.

erik,

great timing,

tomrk,

thanks for the reply. I'm switching service tomorrow, we have 300Mbps now, and I know thats more than enough.

Verizon changed us from hard wired ethernet to Wireless. It is problematic, signal strength and connection issues.

If I can I'm going back to Wired Ethernet, the wires, switch, and router are still in place.

Seems like Xfinity will put most of our recordings on the cloud, anybody have a strong opinion about that? 

@tomrk 

Thanks, that is the clearest explanation I have seen to date of how Netflix dynamically adjusts video compression to adapt to internet congestion.

We are currently watching the Netflix series called, I think, House of Guinness. This appears as almost monochrome, mostly near black, like the eponymous drink, and the sound quality is so bad, we have to have the English subtitles turned on.

A problem I have with most streaming services is that they each need their own "app" and their entire ecosystems are pretty much black boxes.  The black box may, or may not, implement compression when network conditions dictate.  Usually, we just don't get told.

I'd just add that TCP requires every client to send a message back to the server for every packet they have successfully received.  Not an efficient use of the Internet nor server resources and the planet is suffering as a result