MEASUREMENTS: Music servers possibly using UDP packets? Issues for music streaming?

Original from Obaida's Blog.

Qmax last week raised an interesting question about UDP (User Datagram Protocol) and DLNA/UPnP servers, one of the basic "Transport Layer" protocols for data transmissions used for Internet communications. We are likely very familiar with TCP (Transmission Control Protocol) in our day-to-day lives. This is the transport protocol that carries data off our NAS drives, transmits the web pages we read, and ensures integrity of our E-mail data...

What we might not be as familiar with is this other UDP protocol of communication. Whereas TCP is "connection-oriented" and "unicast" sending data between a server and a client through handshaking, UDP is a "connectionless" system where data is "streamed" across the network with potentially multiple destination addresses ("multicast") but without a need for bidirectional communications to address re-transmission in the event of errors detected in the stream. UDP is typically used in broadcast streams like Internet radio, streaming video, VOIP telephony, and multiplayer video gaming because the occasional data error is acceptable and doesn't require re-transmission. Or in the situation with video games, it's all happening in real-time and it's actually preferable to drop a packet here and there than waste time re-transmitting and potentially causing a deterioration in the action. Another use for UDP is with DNS service using small packets. It's faster, and uses less data bandwidth across the worldwide network overall.

This is of interest because some music servers can utilize UDP for data transfer of the media (using another "Application Layer" protocol called Real-time Transport Protocol (RTP)). This fact may seem a little scary to some audiophiles especially with a chart like the one above stating UDP as "unreliable" - after all, perfectionist audio cannot tolerate unreliable communications, right?!

As Måns mentioned in one of the responses, DLNA can actually use both TCP and UDP for transfers depending on the server and client. In fact, when I have a look at the result of:

netstat -a

on the ODROID-C2 when I'm playing music back from the JRiver DLNA server to Volumio 2, it looks like it's just streaming off TCP. No worries... As far as I can tell, the majority of DLNA streaming looks like the TCP protocol is utilized since UPnP/DLNA for the most part is just sharing a "file" link through HTTP with associated MIME type to tell the renderer what kind of media is being served. Also, Logitech Media Server uses TCP for streaming so that's not a problem either for the Squeezebox family of devices (although I hear UDP was used in the old days with the SLIMP3 players).

Nonetheless, for the sake of satisfying curiosity, why don't we still have a look at UDP and answer the question as to whether we should have concerns. More importantly, let's run a test to demonstrate how to check with one's own system.

For the sake of completeness, here's the IPv4 "pseudo header" for UDP packets off Wikipedia:

Notice that there's source and destination addresses. Plus also notice a "Checksum" field which in IPv4 is optional if set to 0. It allows the recipient of the packet to check for data errors but because this is not a bidirectional mode of communication, there is no re-transmission involved - the client cannot tell the server to "send it again" for error recovery even though there is error detection... The client may choose to either ignore the error or if it does utilize the checksum, knows that the packet is erroneous, and may choose to drop the data altogether. Hence the "unreliable" characteristic compared to the TCP way of communicating.

Realize that this diminished reliability and lack of error-recovery is nothing new to digital audio. This is how it is with S/PDIF (eg. TosLink, coaxial, and AES/EBU digital) and USB including asynchronous protocols; they do not typically have error-correcting/retransmission mechanisms. Generally, we expect a relatively error-free communication infrastructure because the data being transmitted isn't "critical" like say banking data, or payrolls, or top-secret weapons plans! A dropped or erroneous bit here and there is likely not going to cause a problem or even noticed and it would be obvious when streaming video or audio once it reaches an unacceptable threshold (like the audible distortions when I used the poor quality USB cable).

Here's then a way to simply test out the UDP integrity of your network path... You can use the iperf command in Linux on both the server and the client. First you might need to install it on your Linux machine and for typical Debian-based Linux, it's with apt-get:

sudo apt-get install iperf

Now, to simulate the transmission on the server side (I'm doing this in my Linux VM which I use to run Logitech Media Server with BruteFir), I run this:

iperf -c 192.168.1.121 -u -t 21600 -b 50M -l 32k

This will get the machine ready to send UDP (-u) to 192.168.1.121 (my ODROID-C2 machine), 32KB datagrams, at 50Mbits/s. I chose 50Mbps to simulate high speed transmission of media. In fact this is very extreme in the context of just audio! We'll talk more about this a few paragraphs down. Notice I have instructed the program to transmit data for 21,600 seconds - 360 minutes or 6 hours straight.

And on the ODROID-C2 command line side which I PuTTY'ed into as described previously:

iperf -s -u -l 32k -i 10

Ready to receive UDP 32KB packets. Display information like jitter, bandwidth, amount of data transferred, and data error every 10 seconds (-i 10) so I can monitor.

Here's the hardware setup being tested:

AMD A10-5800K-based Windows Server 2012 R2 machine with Linux VM ---> NETGEAR Nighthawk R7000 router ---> TP-LINK TL-SG1008D switch (<$20!) ---> ODROID-C2

Total distance from the Windows Server computer to the ODROID-C2 is maybe a little more than 100-feet of mainly generic CAT-6 cable snaking through the walls in my home (the last 6' from the switch to ODROID is just CAT-5e).

Without further ado, the result on the server (Windows Server 2012, Linux VM) side:

The client side (ODROID-C2 running Volumio 2):

As you can see, using reasonably good but typical consumer gear (router, switch), generic ethernet cables (CAT-6 mostly, but I'm sure CAT-5e would be fine), there's just nothing to worry about... Over 6 hours of "torture testing" with 50Mbits/s UDP transmission, 126GB of data was transferred, there were 3 datagrams with errors detected out of a total of 4,120,566 sent! That's an error rate of 0.000073%. Another way to think about it is that out of the 6 hours of streaming, <16ms was affected by some kind of error! I'm quite sure nobody is going to notice :-).

I mentioned above that 50Mbits/s is rather extreme for audio... Realize that for uncompressed stereo 16/44 PCM we just need about 1.4Mbps, for stereo 24/96 it goes up to 4.6Mbps, for stereo 24/192 it's 9.2Mbps, for stereo 32/384 it's 24.6Mbps, and crazy extreme stereo 32/768 it's 49.2Mbps. As for the DSD side, stereo DSD64 is 5.6Mbps, DSD128 goes up to 11.2Mbps, DSD256 is 22.4Mbps, and DSD512 goes to a whopping 44.8Mbps.

I trust there's no need for streaming audio data bandwidth exceeding requirements of 32/768 PCM and DSD512 in the home/consumer environment any time soon, right?! For comparison, remember that NetFlix 4K currently goes up to maybe 20Mbps and typically it's only at ~16Mbps - and that's 4K video and audio folks (though quite significantly compressed)!

If you're wondering, notice that the ODROID-C2 isn't even breaking a sweat - 50Mbps UDP transmission through the gigabit ethernet is only taking up ~2% of the processor time.

Bottom line... Fuggetaboutit. Unless one has really poor network gear, and assuming one is even streaming audio through UDP, the potential data error issue is not likely a meaningful concern. Realize though that I am running a wired gigabit network. For 100Mbps ethernet, 50Mbps sustained streaming might see more errors (again, remember 50Mbps is crazy for audio anyways!).

The other situation is of course WiFi. IMO, one should not be streaming hi-res audio beyond at most 24/96 through WiFi due to reliability in general and risk of buffer underrun issues unless the wireless connection is strong; not just because of UDP concerns...

Here's a quick test using an old 802.11n (2.4GHz) USB dongle I found (Linksys WUSB600N), connected to my router at a modest signal strength of 60%. I booted into Ubuntu for driver support this time rather than the Volumio command line:

Streaming to my ODROID-C2 at 12Mbps with UDP - possibly good enough even for 24/192 and DSD128 transmissions for 2 hours (7200 seconds):

iperf -c 192.168.1.121 -u -t 7200 -b 12M -l 32k

We get this result:

As you can see, it's not as good as wired, but still very reasonable at 0.011% error rate. This means that over the 2 hours (7200 seconds), there were errors detected in 0.792 seconds worth of streamed data. Note that this does not mean there was 0.792 seconds of distortion, just that within those 0.8 seconds or so, a data bit here and there was corrupted which may or may not be audible at all. In my opinion this is not going to be significant. To make this even less significant, remember that 12Mbps is rather quite a significant amount of data... Like I said above, it's probably not prudent to go over 24/96 audio wirelessly (like the limit of the Google Chromecast Audio) which only requires 4.6Mbps or so. In any event, just do the test yourself over your network and see if there's a problem.

BTW: For absolute completeness, I ran the above iperf server/client test using TCP for 6 hours with the gigabit wired ethernet between the Linux VM and the ODROID-C2:

As an asynchronous connection-oriented system, one doesn't specify bitrate with TCP but rather would let the connected computers negotiate data transfer themselves. As you can see, the Windows Server computer and ODROID are able to transmit with error correction at a speed of >600Mbps for 6 hours straight using just default settings, transferring so many megabytes of data that it overwhelms the counting system and is reported as "(null)"! Way beyond the needs of any current consumer media including the current "king" of quality, UHD Blu-Ray which "only" needs at peak ~128Mbps data rate for full-on high quality HEVC/H.265 4K video and Dolby TrueHD multichannel lossless audio plus Atmos! With the much higher data throughput, iperf ran at ~6% processor load on the ODROID. While it was running this test in the background, I was even streaming music to Volumio on the ODROID-C2 and listening to a couple of albums without any hint of error.

Likewise, if I ran TCP with the old 802.11n WiFi USB dongle at full speed, we get reasonably good reliable performance:

Speed varies between 45-60Mbps with ODROID CPU utilization of 8% - I guess the USB WiFi dongle and drivers required a bit more processing... Not bad still and this would handle essentially any reasonable high resolution audio stream.

As you can see, there doesn't seem to be much to worry about here even with UDP within reason for audio bitrates. It works. Given a choice, asynchronous TCP would be preferred over UDP for error-free reliability, and wired ethernet obviously performs better than WiFi in the home environment. By the way, there is one other phenomenon seen at times with UDP - potential for out-of-order sequencing. This is a possibility over the Internet depending on which route the packet takes across large distances; not at issue at home with a single router. I'd actually be very curious which UPnP/DLNA or other audio server transmits over UDP; let me know of any. By the way, considering the performance I'm seeing, apparently no fancy "audiophile" ethernet cables needed :-).

Okay, off to enjoy the "new" Mike Oldfield Discovery / 1984 Suite (CD+DVD set) remaster that just arrived. Enjoy the music. Have a great week everyone, it's May already!

PS: For those who do not have access to wired ethernet and find WiFi not reliable enough, remember that there is another alternative - powerline networking like the HomePlug devices. They have their limitations of course (quality of home wiring, noisy power grids and devices, circuit breakers can impair communications) but before moving into my current home with ethernet built-in, I was routinely using the TRENDnet Powerline 500 AV with better reliability and speed than WiFi in the upstairs rooms and for audio streaming. I see there are the new Powerline 1200 product these days and have heard about 50% speed improvement over the 500 products.