Is there some Prioritization of Audio Traffic / QOS coming with the Roon Client?

Core Machine (Operating system/System info/Roon build number)

Windows Server

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Ethernet Lan 1 Gbit/s, Mikrotik Switch, Pfsense Firewall

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

USB

Description Of Issue

Does any onw or give hints: I have an issue wheras RDP-sessions that are started on the same machine that is running the roon client suffer to a degree of non-usability (at least for my scenario). General network congestion is no possible reason, I suspect the roon client (if running, not even playing) is giving a malus to every other traffic using the same interface in order to assure predence and good quality. Can anyone elaborate on this or are there hidden options one can tune? Moving the roon client to another machine is not an option.

Thanks for some pro Tips!

After reading again and to make it more clear: Imagine you start working via RDP (to remote networks connected via VPN) and are listening to music using Roon client on the same machine. At some point you get lagging behavior in your RDP session, especially if using text-terminals started on the RDP host, this goes to a degree that inputs are lagging for several seconds. You wonder and try and do every possible workaround that is known to you only to find that the issue goes away immediately if you stop the Roon Client or the music playing.

Further Investigation shows that the packets of the TCP stream coming from the ROON Core to the Client and presumably carrying the music don’t have any DSCP flag set at all… at least given I am looking at the right packtes and am not doing some stupid mistake wiresharking. And further reading shows that this is rightly so, the RDP Packets don’t have one neither. The question remains:
I don’t understand how some packets can be delayed at all if there is no congestion on any of the network components involved, maybe this is just some stupid bug in the driver of the Realtek card or something.
Maybe the easiest thing to rule this out is using a different Network adapter and static routing for the VPN/RDP Traffic (or vice versa) and then see how that works

Hi,

I assume you have a VPN client (software) of some kind with RDP through the VPN. Could this be more likely to be the problem. Could be the software ( subnet overlap, MTU adjustment etc) so worth seeing if everything works without the VPN client.

My thinking;

  1. Home network I assume (maxing out gigabit)? I.e. unlikely
  2. Roon is local only by default - so dscp would not be relevant (as dscp is for traffic queues/rules over a router - roon is typically broadcast discovered and local subnet - i.e. never goes through the router). For local network you would be looking as cos setting which is interpreted by the switch (from memory).

That said it could be process priority, or software on the client doing stuff with the card (e.g. TCP offload, MTU etc). I have seen VPN clients do this as well.

As a test (preference) I would try RDP without the VPN just to test. There are a few ways to try this (temp port forward locked down by wan IP) or use splashtop or TeamViewer (all above just to test really).

Personally I avoid RDP if I can for a few reasons.

Worth also noting a few people have had problems with managed switches until flow control enabled.

I used to run a custom build windows 10 machine as a Nas and roon core - just to avoid issues like this, but it worked well for 5yrs.
Eventually went to rock.

I’d also recommend endpoints (I used to use raspberry pi successfully - digiallo to av, hifiberry amp, now arcam etc).

Yes, I have given up on VPN/RPD for remote usage and have moved to Splashtop (or Teamviewer). Never had an issue using Roon client with them.

1 Like

Thanks for all your tips and head-ups.

I did test using different network-cards - one as the gateway and one for the local traffic including roon. I did create a second subnet and did use a second Ethernet-Cable - this way it should be bullet proof and 100% separated. To my astonishment the issue persisted in exactly the same way. So it’s really down to WIN10 or the drivers of the network card or something else. I will now even try a completely different Card as well, the one built in is a two-port card presumably sharing the same chipset / driver.

Messing with the VPN-settings (openvpn to be exact) would be next, also I will look at the switch once again.

If this goes to no avail as well I will likely switch to Anydesk, had best results in regards to responsiveness even in conditions far from optimal. This is no option for all Connections but should work for 90%.

Another Roon endpoint is no possibility because this would mean to replug the Re-Clocker Interface if I want to hear some other audio than roon form my Setup, at least at the moment.

For anyone reading this and also wondering:
I never really got to the core of the problem with 100% certainty, all I did was trying different things.
Using a separate Network card and then separating local Network (including Roon Traffic) from the Internet gateway (I provided a second subnet via V-Lan) brought some relief, but not completely.
One thing that worked quite well was, like suggested by others, switching to a third part Remote-Solution. I chose Anydesk. Only downside is that some some quirks arise with special key combinations in an unpredictable way (and one of those really was a killer: the right Shift key stopped working after some time, that in RDP Sessions started from the remote Desktop itself, so, : yes, it’s complicated).
Final solution and best so far: As it is 95% of the time only one Remote connection that is needed I now use a steady VPN-Tunnel that is operating from my Internet-Gateway to my Remote Working Place and switched back to RDP. I now have the remote subnet coming directly out of a second Ethernet Cable at my Client. This also involves a little Mikrotik Router/Switch directly at my desk and V-Lan so this solution is also not an “easy” one. On may conclude that moving the VPN-Endpoint away from the client was the most important part which was also suggested by someone iirc.

Regards and thanks again for providing Feedback