Roon Switches From UDP to TCP

[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.

[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.

[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!