Does anyone know what ports Roon uses for RAAT? I want to apply DSCP tagging to the traffic to prioritize it for better WiFi performance. I am using Roon on an all Cisco Meraki network (MX, MS, MR).
I believe it uses dynamic TCP ports. You could use wireshark to find out for sure but unless your network is saturated you’ll get zero benefit from prioritizing RAAT packets.
Dynamic ports yes, but in a range perhaps? Why wouldn’t RAAT use UDP like voip since its real time? Less overhead with UDP and re-sending lost packets is useless for music.
I believe early on UDP was used but the switched to TCP a couple years ago. I don’t know anymore.
UDP is prone to errors as it does not resend lost / dropped packets. You dont want that for audio. UPnP also uses TCP for audio data. I think Roon uses UDP for some other things but not for the music bit.
Only in theory. See Roon 1.3 (Build 234) Is Live!
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.
Thanks for the information.
For real time data like VoIP or music, there is no time to resend lost / dropped packets. That’s why VoIP is UDP. The same would make sense for streaming audio.
1 Like
Music from your music server is not realtime so there is no need for UDP. It’s not a live transmission and has time to resend data due to the buffering employed in software and hardware. UDP is only useful for real-time applications such as gaming,VoIP and some times interent radio where lost packets are acceptable to keep the realtime flow. Roon switched to TCP as UDP was causing issues and I believe most people noticed an improvement of stability. You will run in to more support issues using UDP as it’s even more dependant on a good network and given most home users no diddly squat about networking stick with something thats more robust. No music server I know of uses UDP for streaming music only UDP for discovery of devices. It suits it’s purpose more, sending data reliably as possible to a set device.
Music isn’t real time in Roon or any streamed environment is it? The real time nature of digital music on physical media does not translate to streaming with buffers and processing. And we also need to give some credit to RAAT and maybe assume it is competent at what is designed to do.
I agree with @CrystalGipsy, the music stream from Roon is not a real time traffic, you have not a time constraint like the one you have with other interactive real time traffic, like VoIP. There will be buffering at the endpoint. Of course, the music should start playing the sooner the better, but you don’t need it happen within a few milliseconds before you have to discard packages.
But if you are trying to synchronize playback in multiple zones that have been grouped, delays matter. RAAT is very good at this, AirPlay2 is not.
I would argue streaming is real time. It is not susceptible to round trip delay, or propagation delay, but it is very much impacted by jitter and packet loss.
A file, of any kind, is not real time. Your ability to consume the file does not start until you have the whole file. The relationship between the time it takes you to read or view or listen to the file is not related to the size or length or time it takes to transfer the file. The file is not real time.
Streaming media is real time. There is a direct relationship between packets arriving at the playback destination and when they must be played back to be “in time”. The amount of time it takes you to consume the stream is close to the amount of time it takes for the file to be transferred. Things like packet loss and out of order packets, unlike with the transferring of a file as they are recovered before you consume the file, will directly impact the ability of playback to be “in time” because there isn’t time to correct these errors before you are to consume the audio that never arrived.
Also most playback devices have much smaller buffers to receive chunks of the audio than you’d expect (like milliseconds).
1 Like
I wonder whether the following rule would be sufficient in order to match the TCP packages created by the RAAT server targeting Roon Bridges, Amplifiers
source-ip-address ROON_SERVER_IP
ip-protocol TCP
destination-port 10000-65535
background: I’m using a JunOS EX switch and would like to put the RAAT-related TCP packages into the “streaming” queue and once the packages are ending up in egress, proper queuing and retagging (802.11q, DSCP) is applied.