Thanks for all the additional info! Upon a fresh review of the Roon logs you’ve sent over from the issue mac studio, we’re seeing the potential of some conflicting IPs - and a potential virtual network interface on the mac itself.
If possible, are you able to temporarily disable all but a single active subnet across your local network, reboot your router and roon devices, and see if the same issue occurs?
And my apologies if this has been glazed over - are you able to temporarily set up a direct ethernet connection with the mac to your router?
So just to be clear, the current version of Roon is the first time this has been a problem, so something changed between the prior version and this one, as my system hasn’t changed (ie, I haven’t updated my VPN software, or even changed the prefs in it).
So… I can now reliably have all my local devices fail to show up, and bring them back somewhat reliably.
It involves my VPN, which I generally keep on all the time, both for work, and other reasons. Here are the permutations:
Starting from a quit Roon app, and my VPN on(NordVPN, and only using them for VPN, not any of their other services like DNS. Connecting to any of their servers has the same result): No local zones (only zones on my LAN)
Disconnecting the VPN, with Roon still open: Clicking on the zones list will have the local zones re-appear (I can watch it repopulate over the course of about 0.5 – 1 seconds)
Hitting “Connect” on my VPN app: Local zones STAY AVAILABLE.
Quitting Roon with the VPN connected, and restarting Roon: Local zones are NOT available.
Additional detail:
If a local zone was the active zone in the app when it was quit, and the VPN is on when Roon is restarted, I will get the “Select a Zone” button, rather than the usual play controls.
The VPN software has a ‘hide on LAN’ option which is OFF (my machine is perfectly visible to others on the LAN)
Other apps on the machine that use sound can target any of my locally attached sound output devices (ex: MM1s, the USBPre2) regardless of VPN status (assuming Roon isn’t currently playing to it in exclusive mode, obvs).
Question:
Why would Roon see all the zones on the LAN just fine when the VPN was on, but not the local physically attached (USB) zones which are not ever available on the LAN via other machines? (also note Roon could always see the machine it was on regardless of VPN status as an AirPlay option, even if it couldn’t see my USB connected speakers/headphones)
Thanks for those reproduction steps! I’ve forwarded them to the QA team to see if they can reproduce the issue on their end.
It sounds like the VPN is affecting RAATServer specifically, this is the module in charge of USB/connected zones. Let’s see if QA is able to reproduce with your steps, though it is possible other VPNs have different behavior.
Thanks for your patience while our team looked into this further. Our QA team has attempted to follow the exact reproduction steps provided:
Quit Roon completely, with VPN already enabled.
Launch Roon → check if local zones appear.
Disconnect VPN while Roon is running → check if local zones re-appear.
Reconnect VPN while Roon is still open → verify if local zones remain available.
Quit Roon with VPN active, then launch Roon again → check if local zones are missing.
In all cases of their testing on two different VPN providers (ClearVPN + ProtonVPN), the audio devices remained visible and no other audio devices were lost. The behavior was consistant regardless if the VPN was on/off or reconnecting.
It seems like the issue may impact NordVPN differently, and if that’s the case we would suggest setting up a “split-tunnel VPN route”, where NordVPN isn’t impacting Roon/RAATServer.
We wanted to revisit a question you posted that went unanswered above.
Why would Roon see all the zones on the LAN just fine when the VPN was on, but not the local physically attached (USB) zones?
NordVPN likely installs a virtual network interface which it presents to MacOS as primary for outbound traffic. But macOS keeps the physical network interface alive for all incoming mDNS traffic, including the multicast device announcements from your networked Zones. MacOS passes these to Roon on the regular interface even when NordVPN is online.
USB endpoints communicate with Roon via Apple’s coreaudio daemon, which is likely bound to the “primary” network interface, which MacOS has delegated to NordVPN. So, these physically-connected devices are ironically invisible in a quirk of local network interfacing.
Other consumer VPNs with heavy-handed virtual network interfaces will likely have similar issues with local device discovery. I can reproduce some of these issues intermittently on Mullvad VPN.
The vast array of possibilities for this interface logic is generally too broad for us to support. It’s for this reason that we usually recommend disabling consumer VPNs with Roon unless strictly necessary. However, @noris’s suggestion above is a technically sound starting point. Please let us know if we can assist further. Thank you!
Sadly, modern MacOS (Big Sur and later, and only Intel Macs) make it impossible to do split tunneling, so that’s not really an option. (insert long rant about how MacOS has gone downhill for years).
While It’s not ideal, my workaround does indeed work… as long as the app doesn’t crash, I can just pause the VPN, start Roon, then enable the VPN to retain my USB connected devices.
One followup question re: Core Audio being bound to the primary network interface… Notionally, I get this, but that explanation seems to be at odds with the notion that the local USB devices persist when I turn on the VPN after I launch Roon. If the network was ostensibly switched out from under it, then the local devices should disappear when the VPN is activated, as they DO come back if I turn off the VPN while Roon is still running.
Thanks for the follow up, and great question. Yes, at first glance it does seem contradictory. The key is that there are two different subsystems involved, and they respond very differently when the primary network interface flips under a VPN.
It’s likely the case that Core Audio itself has zero dependency on networking. Your USB DACs, built-in speakers, HDMI audio, etc. remain enumerated and available regardless of what’s happening on the network. Nothing in Core Audio re-registers or tears down devices when the network interface changes.
Roon’s RAAT networking layer (which handles networked zones, discovery, and RAAT endpoints) is bound to the primary network interface and IP stack that exists at launch.
Your intuition is correct: “If the network switched out from under Roon, why aren’t all devices affected?”
Because Roon has two distinct device subsystems:
Local Core Audio backend (usually is stable regardless of network)
RAAT network backend (fragile with respect to interface changes)
Right, which is why I am still confused as to why it is my local Core Audio stuff that is disappearing when I turn on/off my VPN. The networked/RAAT stuff is fine, and is always seen in all circumstances/permutations.
Sorry for the confusion. It’s a question of which network interface Roon/RAAT prioritize to look for coreaudio on launch and after network change events. Roon will retain a valid binding to coreaudio if it was able to reach it through the standard network interface when Roon launched. But if Roon first launches with NordVPN’s virtual network interface advertised by the OS as primary and available, Roon will get confused and look for coreaudio there.
Roon will retain a valid binding to coreaudio if it was able to reach it through the standard network interface when Roon launched. But if Roon first launches with NordVPN’s virtual network interface advertised by the OS as primary and available, Roon will get confused and look for coreaudio there.
Right, but again, these aren’t networked end points. These are local to the machine I’m using the app on. From my understanding, Core Audio doesn’t bind onto the network at all. My problem IS NOT with RAAT end points. Only with my local USB attached, non-networked Core Audio devices.
RAAT/Networked stuff has always been solid, and is not the issue.
Anyway, noticed a software update today, so I’m going to test that to see if it magically fixes it. ::touches wood::
