Nell'ultima release di Roon - 1.3 (Build 234) - sono passati da UDP a TCP.
Queste sono le 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.
Rispondi quotando
