Roon Switches From UDP to TCP

[The Computer Audiophile]

Hi Guys - The latest release notes for Roon 1.3 (Build 234) indicate the company has switched from UDP to TCP and lists more details about this. 

 

This may be a bit geeky for many readers, but it's also very interesting for many of us. 

 

From the release notes:

 

 

RAAT Audio Streaming Optimizations

 

Most audio streaming protocols are designed, implemented in hardware, and then set in stone. This happens because updating firmware in hardware devices is difficult, and when that hardware is made by dozens of different manufacturers it’s nearly impossible. That’s why most AirPlay users never install a firmware update--the device is speaking the same AirPlay protocol it did on day one.

In an ecosystem like that, evolving is difficult--too many changes and you end up with a range of devices each with slightly different behavior. This is a nightmare for QA and support, so device implementations for protocols like UPnP AV and AirPlay are often set in stone.

 

When we set out to design RAAT, we hoped for a brighter future -- a future that can evolve with our budding hardware ecosystem. Trying to push firmware updates to Roon users via our 60+ hardware partners wasn’t realistic, so we designed RAAT to work differently: Instead of baking the audio streaming protocol into the device firmware, the firmware contains the absolute minimum needed for us to "boot" a second piece of code delivered to the device the time when the Roon Core makes its connection to the device. This second piece code--delivered "just in time"--defines the streaming protocol that Roon uses to speak with RAAT devices.

 

Today's release of the core includes a re-design of RAAT's audio streaming protocol that uses TCP instead of UDP to transmit the audio stream.

 

In day-to-day life, most of the protocols you use are TCP-based--browsing the web, viewing Netflix or Youtube. Streaming audio using TIDAL, Spotify, OpenHome, UPnP, MPD, or SMB. The two most popular UDP streaming systems that most people have contact with are AirPlay and Skype.

 

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.

 

We found that using TCP reduces CPU load on the audio device and in the core--primarily by reducing the context switching overhead associated with “waking up” for each packet. Using TCP also allows us to offload work associated with re-assembling the packetized audio stream from RAAT to the operating system kernel on the audio device, where it can be implemented more efficiently and simply.

We also found that TCP is a lot "friendlier" to poor networks and routers. Not all router manufacturers perform extensive QA with high-resolution UDP audio streams, but they all test to make sure Netflix and Youtube (both TCP-based) work. TCP is also less likely to create trouble with exotic network setups--managed switches, jumbo frames, etc. If you have experienced trouble with these, it's definitely worth taking another shot to see if the new protocol is easier on your network.

 

This change rolls out as part of the update to your Roon Core--which will use the new protocol when speaking to all RAAT-based zones. Aside from updating the core, no firmware or software updates are required on any of your devices.

 

[wklie]

Yes, I noticed that and was surprised.  Need to find time to retest our devices, even though I'm sure Roon Labs must have already done extensive tests.

[Quadman]

I spent 5 hours listening last night and felt there was an improved sound.  Depth layering was more distinct, width was wider and layers (front to back) had more presence and transparency at each level.  Changing protocol could make that type of difference?  Kind of like when I went from a OS SSD with TLC memory to one with SLC memory.  I use HQP with roon and upsample to DSD512, win10 pro standalone PC.

[austinpop]

I use an sMS-200ultra endpoint, and did not notice any difference in SQ. However, I cannot tell if TCP is engaged as soon as you use Core v 1.3 build 234, or if there is an upgrade needed on the Roon Ready code version of the endpoint. The sMS-200 v0.3.8 firmware runs Roon Ready v1.1.19.

 

If I am reading correctly, there should be very minimal dependence on the Roon Ready version, because as stated, the design of RAAT is to deliver the protocol code to the endpoint "just in time" from the core, rather than baking it into the firmware. This would suggest protocol changes like this should kick in immediately.

 

If I were motivated, I could do some packet captures and look for the presence of absence of UDP datagrams on the wire, but honestly, I'm not really motivated. As long as SQ does not degrade... I also hope this reduces the incidence of drop outs, pauses, and other glitches that can plague a UDP-based scheme.

[mjb]

Strange that they would do this actually....

 

 

http://microchipdeveloper.com/tcpip:tcp-ip-transport-layer-layer-4

[Quadman]

I was a bit surprised at the switch too and this quote caught my eye,

"We found that using TCP reduces CPU load on the audio device and in the core--primarily by reducing the context switching overhead associated with “waking up” for each packet. Using TCP also allows us to offload work associated with re-assembling the packetized audio stream from RAAT to the operating system kernel on the audio device, where it can be implemented more efficiently and simply.

We also found that TCP is a lot "friendlier" to poor networks and routers"

And listening Wednesday, i kept telling myself i was just hearing things but song after song I could not deny that the layered depth was more defined and images more palpable, edge to edge was wider as well. It does appear from their wording that once the core is updated then nothing else needs to be done so @austinpop should not have to do anything with his SMS toys to get the benefit.  I run a more direct USB chain than his heavily modified ethernet/usb chain and that may have some effect on the results.  I go from PC via a dac-up usb port-AQ jitterbug- 2m USB- regen-custom 6" silver usb cable and I power regen from a DIYinHK low noise linear PSU that has small transformers right after the ac input.  Hopefully next week i will get the isoregen.

 

I accidentally made one other change that night before i knew the roon would update, I raised my CPU speed and cpu voltage a touch going from a conservative 4 gHz and 1.26v to 4.4 gHz and 1.30 v.  (i7-6700k), that possibly could of had an effect as well, but logic tells me more speed and voltage equals more noise on ground plane which should have reduced SQ not improved.  More listening tonight and more learning.  There is so much we do not understand in streaming digital.

[austinpop]

@Quadman - yes I agree. In fact, reading the build notes confirms it:

 

This change rolls out as part of the update to your Roon Core--which will use the new protocol when speaking to all RAAT-based zones. Aside from updating the core, no firmware or software updates are required on any of your devices.

 

It does make sense that if TCP processing can be done more efficiently, with lower CPU and memory utilization, this should improve SQ. Looking back, I just didn't get a chance to do a careful before and after comparison, which is why it's impossible for me to tell if there was an improvement in SQ.

[kennyb123]

3 hours ago, Quadman said:

And listening Wednesday, i kept telling myself i was just hearing things but song after song I could not deny that the layered depth was more defined and images more palpable, edge to edge was wider as well.

 

This is what I thought I heard as well - along with a bit more "pop" too.

[mjb]

1 hour ago, austinpop said:

It does make sense that if TCP processing can be done more efficiently, with lower CPU and memory utilization, this should improve SQ.

I don't understand how a much simpler protocol (UDP) can require more CPU/memory utilisation! I'm genuinely interested why Roon has done this, I don't believe "TCP processing can be done more efficiently" is the reason.

[austinpop]

39 minutes ago, mjb said:

I don't understand how a much simpler protocol (UDP) can require more CPU/memory utilisation! I'm genuinely interested why Roon has done this, I don't believe "TCP processing can be done more efficiently" is the reason.

 

Easier to understand if, like me, you worked on network protocol stacks in the OS kernel - in a previous life.

 

This is a clue, from the build 234 notes:

We found that using TCP reduces CPU load on the audio device and in the core--primarily by reducing the context switching overhead associated with “waking up” for each packet. Using TCP also allows us to offload work associated with re-assembling the packetized audio stream from RAAT to the operating system kernel on the audio device, where it can be implemented more efficiently and simply.

 

Without actually digging into the code, it's impossible to say for sure, but this points strongly to two features found in typical OSes and NICs:

1. Interrupt coalescence, or interrupt moderation
2. TCP offload engine (TOE), available in many NICs.

You can Google these for more details, but the point is that it is not hard to imagine how TCP processing can be optimized. Yes, UDP is simpler, but remember for this application, audio streaming, while occasional packet loss can be tolerated, it is certainly not desirable. So I would bet that RAAT was handling out-of-order UDP datagrams, UDP datagram loss, etc, which they can now delegate to the OS and/or the NIC.

 

Trust me - I'm sure this decision was arrived at after a lot of tuning and optimization!

[Quadman]

I wish I knew more about these protocols and software efficiencies, I have no IT background and some things that people discover and report that in reality should not make a difference do.  Fascinating.

[wklie]

I can confirm I'm seeing significant processing efficiency improvement on some of our hardware, based on a preliminary test.

 

As for SQ, could this be the start of SQ debate of TCP vs UDP, along the lines of PCM vs DSD, WAV vs FLAC, effect of computer digital EMI/RFI noise, audiophile (interconnect / speaker / network) cable, etc.?

[Quadman]

I did note a more even work distribution among the 8 cores.  I upsample to dsd512 with HQP and before the switch 1-2 cores would run near 50% and 1-2 near zero.  Now it appears more even.  Overall the cpu load does not seem much changed.

[Bob Stern]

On 6/8/2017 at 4:03 PM, austinpop said:

If I were motivated, I could do some packet captures and look for the presence of absence of UDP datagrams on the wire, but honestly, I'm not really motivated. As long as SQ does not degrade... I also hope this reduces the incidence of drop outs, pauses, and other glitches that can plague a UDP-based scheme.

 

With UDP, packets can arrive in the wrong order if they are routed through different network paths having different latencies.  Obviously, the audio will be distorted if the sample values are scrambled in time.

 

TCP specifies the order of the packets as well as requesting retransmission of dropped packets.

 

I'm surprised the shortcomings of UDP for hi-res audio haven’t been discussed before.

[lmitche]

It is likely that there would be another SQ gain if the Roon/Hqplayer link recognized that they were on the same host, and used a faster mechanism then TCP/IP for inter-process communication.  I believe that Microsoft enabled such a mechanism in Windows 8 at the OS level.

 

I remember moving from localhost TCP/IP connections on Oracle to a shared memory pipe for local connections and getting orders of magnitude size throughput improvement.

[davide256]

On 6/11/2017 at 2:19 AM, Bob Stern said:

 

With UDP, packets can arrive in the wrong order if they are routed through different network paths having different latencies.  Obviously, the audio will be distorted if the sample values are scrambled in time.

 

TCP specifies the order of the packets as well as requesting retransmission of dropped packets.

 

I'm surprised the shortcomings of UDP for hi-res audio haven’t been discussed before.

Thanks Bob, I thought this was the case

[Miska]

On 6/11/2017 at 4:02 PM, lmitche said:

It is likely that there would be another SQ gain if the Roon/Hqplayer link recognized that they were on the same host, and used a faster mechanism then TCP/IP for inter-process communication.  I believe that Microsoft enabled such a mechanism in Windows 8 at the OS level.

 

I remember moving from localhost TCP/IP connections on Oracle to a shared memory pipe for local connections and getting orders of magnitude size throughput improvement.

 

On Linux/Mac it would be easy to use local (Unix domain) sockets instead. Windows is strange animal in that respect (too). In fact Linux pretty much does that automatically for localhost anyway. Not sure if Windows is clever enough to use faster mechanism for localhost.

 

But overall, given the low data rate going between Roon and HQPlayer, it is not much concern which way is used...

 

[lmitche]

4 hours ago, Miska said:

 

On Linux/Mac it would be easy to use local (Unix domain) sockets instead. Windows is strange animal in that respect (too). In fact Linux pretty much does that automatically for localhost anyway. Not sure if Windows is clever enough to use faster mechanism for localhost.

 

But overall, given the low data rate going between Roon and HQPlayer, it is not much concern which way is used...

 

Thanks for your thoughts, You are probably right, no need to fuss at these data rates.  Nevertheless, I think Windows 8 brought a new capability here.  Let me take a look and get back to you.

[lmitche]

Found it!  It's called Fast TCP Loopback.  Here is the Technet article:

 

https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/

 

 

[Theobetley]

On 6/8/2017 at 5:52 PM, Quadman said:

I spent 5 hours listening last night and felt there was an improved sound.  Depth layering was more distinct, width was wider and layers (front to back) had more presence and transparency at each level.  Changing protocol could make that type of difference?  Kind of like when I went from a OS SSD with TLC memory to one with SLC memory.  I use HQP with roon and upsample to DSD512, win10 pro standalone PC.

I just switched to Roon from HQP and this thread explains why I am hearing what I am hearing. Harry Pearson used to describe it as 'grain structure' but I am hearing no grain structure on Roon. Just like reality. In my opinion Roon is a significant sq opportunity over HQP. Way to go  Roon!

[Miska]

3 hours ago, Theobetley said:

I just switched to Roon from HQP and this thread explains why I am hearing what I am hearing. Harry Pearson used to describe it as 'grain structure' but I am hearing no grain structure on Roon. Just like reality. In my opinion Roon is a significant sq opportunity over HQP. Way to go  Roon!

 

I wonder what on earth this has to do with HQPlayer!? What is the relation? 

 

[Theobetley]

Just mentioned in passing.

[Cebolla]

14 hours ago, Miska said:

 

I wonder what on earth this has to do with HQPlayer!? What is the relation? 

 

A bit like the apparent fanboy lack of concern for the original design decision that eventually brought about the U-turn, for something so universally obvious. I wonder what other hidden 'gems' remain?