Roon Update Causing Playback Issues on Recent Album (ref#9AVM7F)

Support
1

What best describes your playback issue?

· Music doesn't start when I press "Play"

What type of Zone is affected by this problem?

· *Directly-connected Zones* are affected.

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Only local library *music is affected.

Where is your local content stored?

· On the same machine where RoonServer is running, internal drive

Please try playing content of a lower sample rate (44.1kHz or 48kHz), does this work as expected?

· No, lower sample rates are still affected

Do you have an approximate timestamp of when the issue last occurred?

· 10:09 PM MST

What are the make and model of the affected audio device(s) and the connection type?

· Same as previous ticket ref#I9IMEI

Describe the issue

The same issue as described in my recent ticket (ref#I9IMEI) has reappeared. The songs are just going through all songs on the albums in quick succession and failing to play. I reinstalled the driver from the given link in the previous ticket but the same issue persists!

The only thing that has changed was the Roon update on the same day as I submitted my previous ticket. Roon had worked swimmingly up until then leading me to believe there might by an issue within the update. All other programs on my computer play audio the same files just fine.

Describe your network setup

Same as previous ticket ref#I9IMEI

2

Hey @Travis_Ernewein,

Thanks for writing back in, and I’m sorry to hear you’re having issues again!

From your previous thread, it sounds like editing your audio device settings to ensure WASAPI is set to exclusive mode seemed to help. Have you been able to try this post update? That, or testing the dedicated XMOS driver?

An update shouldn’t change or touch any of your previous settings, so I’d be surprised if anything was changed, but it’d be good to check and confirm.

Here are some next steps in troubleshooting:

1. Disable “Event Driven Mode” on the JDS Labs EL DAC II+ Balanced In Roon: Settings → Audio → click the gear next to your DAC → Device Setup → scroll to find “Event Driven Mode” and turn it off.

2. Switch from WASAPI Exclusive to WASAPI Shared (as a test) Temporarily change the output mode to confirm whether the issue is exclusive-mode specific. If shared mode plays fine, the problem is definitively in how build 1658 handles event-driven exclusive WASAPI.

3. Disable DSP/Bit Depth Upgrade temporarily The logs show Roon is upsampling 24-bit to 64-bit internally via a ParametricEQ and then truncating to 32-bit. Try disabling all DSP (Settings → DSP) and testing playback — this rules out a DSP pipeline timing issue introduced in 1658.

We’ll be on standby for your reply and results! :folded_hands:

3

Hi Benjamin,

Yes as per the previous ticket I am using their most up to date XMOS driver.

  1. Disable Event Driven Mode: No change
  2. Disable WASAPI Exclusive mode: No change
  3. Disabled Parametric EQ: No change

I’m just trying to think if anything changed in my setup other than the Roon update, but can’t come up with anything.

I should also note that Roon doesn’t let go of exclusive mode even after it fails to play any music. I must go into task manager and force quit Roon Server.

4

Hey @Travis_Ernewein,

Thanks for the update! Sorry to hear you’re still having issues.

From a fresh Roon Server diagnostic report, we can see that the failure is a clock synchronization failure between Roon’s RAAT sender and the JDS Labs EL DAC II+ Balanced endpoint, not a WASAPI exclusive mode issue per se. Every single track failure shows this exact pattern:

failed to sync sender clock to endpoint JDS Labs EL DAC II+ Balanced
failed to sync clocks with any endpoints..giving up
Track Stopped Due to Error

There’s also a secondary clue: on 05/11 the DAC returned RAAT__OUTPUT_PLUGIN_STATUS_DEVICE_IN_USE immediately at startup, meaning something else had grabbed the WASAPI exclusive handle before Roon could claim it, and Roon then couldn’t release it (hence needing to force-quit via Task Manager).

Some additional steps to try:

1. Try the ASIO driver instead of WASAPI. The logs show a “JDS Labs USB Audio Device” ASIO driver is already installed and was previously visible to Roon. Go to Settings → Audio and enable that ASIO endpoint instead of the WASAPI one. ASIO bypasses the Windows audio stack entirely and uses a different clock model, this would sidestep the clock sync failure completely.

2. Check for a conflicting exclusive-mode audio application running at startup. On 05/11 at startup, the DAC returned DeviceInUse before Roon even tried to play anything, something else owned the exclusive WASAPI handle. Check what’s running: Voicemeeter, Discord, Spotify, any other audio app that might grab the device on login. If you find one, close it before starting Roon.

3. Try unplugging and replugging the DAC’s USB cable after Roon Server starts but before pressing Play. This forces the WASAPI device ID to re-register, which may reset the clock sync state.

We’ll be monitoring for your reply, Travis! :+1:

5

Hi @benjamin

  1. AISO driver instead of WASAPI: No dice. I disabled the WASAPI one and enabled AISO but same symptoms.
  2. I disabled all programs from task manager that may be using any audio after re-enabling WASAPI. Then started Roon after ending the task in task manager. No change in symptoms.
  3. Force quit Roon, unplugged the DAC, plugged back in, started Roon. No change in symptoms.

ALL other programs appear to be able to play audio no problem. I even went so far after this to install Music Bee and put it into WASAPI exclusive mode. I encountered no issues playing audio.

Again, this issue only started with Roon after the update noted in the previous ticket. Thank you for the additional troubleshooting steps, I hope it helps to narrow down the issue.

6

Hello @Travis_Ernewein ,

Thanks for giving that a try. Please try to reinstall RAATServer as the next step, I will provide instructions below.

You can generate a new RAATServer instance on your device by following these instructions, but please be aware that this will reset your Roon Settings -> Audio Tab to factory settings and I would advise making a backup of any custom DSP settings you have:

  • Create a Backup of your current Roon database
  • Exit out of Roon/RoonServer (from the taskbar)
  • Navigate to your Roon’s Database Location
  • Find the folder that says “RAATServer”
  • Rename the “RAATServer” folder to “RAATServer_old”
  • Restart the Roon App to generate a new RAATServer folder

Let us know if this helps.

7

Same deal. Verified a new RAATServer folder was generated.

8

Thanks for giving that a try @Travis_Ernewein!

We reviewed another fresh diagnostic report from your server, and see that the clock sync failure is not device-specific and not driver-specific, it’s happening identically across:

  • JDS Labs EL DAC II+ Balanced via WASAPI exclusive (both with event_driven_mode on and off)
  • JDS Labs USB Audio Device via ASIO
  • Both failing in exactly the same way: RAAT sends a setup request → endpoint responds Success with a clock_port → Roon's sender tries to sync to that port → fails every single time, immediately gives up
The only successful playback in the entire log set is from 05/02–05/03, running into the WASAPI endpoint. After that date, 100% failure rate regardless of output mode.

There are also two distinct WASAPI device IDs across the logs, {869cc35d…} (older logs) and {eaa060ab…} (newer logs), which indicates the DAC was re-registered in Windows at some point, likely from USB replugging during troubleshooting. This is expected and not the cause.

The RAAT clock sync uses a UDP loopback connection to the clock_port that RAATServer reports. In every failed attempt, the endpoint is responding and connected, audio data is being buffered, but Roon’s sender cannot reach that UDP port. Since this fails on both WASAPI and ASIO, the issue is upstream of the audio driver: something is blocking Roon’s loopback UDP traffic on this Windows machine.

If you haven’t yet, check Windows Firewall / security software for loopback blocking. A Windows Defender Firewall rule change, or a third-party AV/endpoint security update, may be blocking Roon’s internal UDP loopback traffic. Try:

  • Open Windows Defender Firewall → Advanced Settings → Inbound Rules
  • Look for any rule blocking RoonServer.exe or RAATServer.exe on UDP
  • Temporarily disable Windows Firewall entirely as a test (not permanently), then try playback
I would also test playback to the System Output In Roon Settings → Audio, enable the System Output zone and try playing to it. If that also fails with clock sync errors, this confirms the problem is in Roon's networking/loopback layer on this PC specifically. If System Output plays fine, the issue is more constrained to the USB audio path.

Let me know if any of the above helps, thanks Travis! :+1:

9

Looked at my computers firewall. RoonServer.exe and RAATServer.exe are explicitly allowed connections on all internal UDP. No specific rules are setup to block them. I also took the extra step to delete the allow rules, uninstall roon, and then create the exception rules again when prompted by Roon setup.

I disabled both windows firewalls and the same issue happened.

I also changed the audio playback to system output in Roon and the same issue occurred.

Again all other programs that play audio have no problem doing so. Even MusicBee in WASAPI exclusive mode has no issues. Its only since the Roon update in my previous ticket that I cannot play anything on Roon.

Screenshot 2026-05-18 102517
Screenshot 2026-05-18 1025173440×1440 269 KB

10

@Travis_Ernewein,

Thanks for sharing the details from your firewall settings and for running those additional tests.

Looking closely at the screenshot you provided, there is a very strong clue as to why the UDP loopback connection is still failing.

In the Profile column for raatserver.exe, roon.exe, and roonappliance.exe, the allowed connection is strictly set to Private.
If your Windows network profile recently switched from Private to Public (which can happen after a router reboot, driver update, or Windows update), Windows Defender will completely ignore those exceptions and block Roon’s internal UDP traffic, leading exactly to the clock sync failures we are seeing across all audio devices, including System Output.
Here are the next steps to tackle this network-level block:

  1. Verify Your Windows Network Profile
  • Go to Windows Settings -> Network & Internet.
  • Select Ethernet or Wi-Fi (depending on how your PC is connected).
  • Click on your current network connection.
  • Ensure the Network profile type is set to Private, not Public.
  • (Alternatively, you can go back to the Advanced Firewall settings in your screenshot, double-click the Roon/RAAT rules, go to the "Advanced" tab, and check the boxes for all profiles: Domain, Private, and Public).
2. Check for Third-Party Network/Security Software Even with Windows Defender disabled, third-party software can intercept local loopback traffic.
  • Are you running any non-Microsoft antivirus (like Bitdefender, ESET, etc.), a VPN (Tailscale, NordVPN), or any gaming-specific network priority tools (like Killer Control Center or ASUS ROG GameFirst)?
  • If so, please temporarily disable or completely exit these programs, as they often bypass standard firewall rules.
3. Reset the Windows Network Stack Since the issue affects the fundamental 127.0.0.1 loopback needed for RAATServer, resetting the Windows network stack can clear up corrupted routing tables:
  • Click the Start menu, type cmd.
  • Right-click Command Prompt and select Run as administrator.
  • Type netsh winsock reset and press Enter.
  • Type netsh int ip reset and press Enter.
  • Restart your PC and try playing audio in Roon.
4. Temporarily Disable IPv6 (As a test) Sometimes Windows incorrectly prioritizes IPv6 for local host connections, confusing internal Roon processes waiting for IPv4.
  • Go to Control Panel -> Network and Internet -> Network Connections.
  • Right-click your active network adapter and select Properties.
  • Uncheck Internet Protocol Version 6 (TCP/IPv6).
  • Click OK, restart RoonServer, and test playback.
Please start with Step 1, as the firewall profile mismatch is the most likely culprit based on your screenshot. Let us know how it goes!
11

Hi @alex_h

So I performed all steps in sequence. Got to step 2 and disabled my Proton VPN and I can make Roon play now when VPN is disabled.

Given disabling my VPN is a non-starter I tried to enable split tunneling where Roon.exe, Roonserver.exe, RAATServer.exe, RoonAppliance.exe are applications that are excluded from the VPN connection. This didn’t seem to work, so I’m wondering if theres anything else I need to try?

12

Hi @Travis_Ernewein,

That was excellent diagnostic information, and it points us to the VPN as the blocker. Since Roon starts playing normally when Proton VPN is disabled, the issue is not with playback itself, but with how the VPN is handling Roon’s local traffic.

Doing a web search, it looks like there are a few other people who have mentioned Proton’s split tunneling feature is not working correctly, perhaps this will help:

. From that thread:

> I think its because of the ipv6 setting, they changed something with the update. For split tunneling to work for me I have to go to advance setting and then disable ipv6 support, for ipv6leak protection the setting doesn’t seem to matter, but I turn it on.

> I did like 50 different tweaks to try to resolve the issue but what finally did it was doing a Network Reset. Simply search Network Reset in windows search. It’ll shutdown your pc in 5 minutes and reset all your drivers/adapters and take everything back to stock settings.