Loosing Connection to Core with Chord Qutest and WASAPI

I occasionally lose connection to Roon Core. I can’t reliably reproduce the problem. I’ve noticed it when I’m browsing, “New Releases for You”, section that features Tidal and Qobuz tracks, when I’m just starting a listening session, or sometimes during listening. Music tends not to stop but the Roon Remote app says that it lost the connection to the core and takes several seconds to come back.

If this happens when browsing, “New Releases for You”, then the Roon Remote UI kicks me out of New Releases and back to the top level. I also notice that my raspi device running Ropieee that I use as a display (not as a streaming endpoint) stops behaving properly.

Any idea what might be going on or how I can go about troubleshooting?

Describe Your Setup

System Details:
Roon Server: Windows 10 fanless PC ASUS mini ATX Q87T/CSM motherboard; running headless; sleep mode configured to “never”
Local library on 6TB USB drive connected to the PC (about 4500 albums and 53,000 tracks)
Roon Server 1.7 (build 710) on Windows 10 PC
Roon Bridge 1.5 (build 571) on rasp 4B
DAC Chord Qutest DAC (USB connection from Matrix Element H PCIe USB in PC)
16GB RAM; 2.8 GHz dual core Celeron; Windows 10 Pro
Roon Remote: Macbook Pro

Networking: Netgear 4 port ethernet hub connecting PC and rasp. Netgear hub connected to Google mesh wifi. Roon Server PC and raspi have WiFi turned off and they are each running on an assigned IP address. Macbook Pro connects over WiFi to Roon Server

I had intermittent losses despite minimal wiring and a new Enet switch and high end router. I finally gave up after a couple of years and hard wired my Meridian 861 directly to my Mac Mini (Roon) via a 2nd Ethernet port on Mac via a Caldigit dock. Voila!

I’m not loosing audio. It’s like some components of Roon Server are restarting that cause the display on the Roon Remote on my Macbook and the display on RopieeeXL to reset or hang. If I do nothing it will eventually resolve itself. It takes several seconds for Roon Remote on my Macbook and probably tens of minutes for RopieeeXL to sync back up.

My situation different, but one thing I suffered with from Day 1 was lag and only intermittent response using my Meridian remote. I was frankly shocked in a positive way to find that it started working perfectly (essentially instantaneous) as soon as I direct wired the Enet. I’m a old Sooloos user and had intermittent network issues in the past too. At one point, I had two switches between Sooloos server and the 861. Removing one switch helped but the problem remains. I think they could do a lot better handing network lags. Perhaps a deeper buffer would help, I don’t know. In any case with my direct wire, the issues have all been resolved.

Updating my original post with a bit more information. I’m experimenting using ASIO from Roon Server to my Chord Qutest DAC and that seems to be more stable. My normal configuration is WASAPI. I looked at the Roon Server log last night and found the following errors that I think correspond to the problems that I’ve been having with WASAPI:

01/27 19:52:09 Trace: [push] restarting connection (Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.)
01/27 19:52:09 Trace: [push] retrying connection in 42453ms

I have no idea if this is related to problem I’m seeing or how it could relate to WASAPI vs ASIO. The Chord has an ASIO driver for the Qutest. I prefer to use WASAPI because I have a handful of audio files that I converted from DSD to PCM and maxed the sample rate in the conversion. They’re at 352 kbps and I get drop outs over ASIO that I don’t get with WASAPI. It’s silly that I converted them to 352kbps; no need to do that for a DSD128 file.

I’m also testing going through raspberry pi streamer to the DAC. That seems to work too. This seems to suggest that there’s some interaction happening with the Qutest using WASAPI and Roon Server that’s causing my problems. I have work arounds but I would really like to find out the root cause from the Roon team.

The failure mode is narrowed down to WASAPI on Roon Server with Chord Qutest connected to Roon Server over USB. In that configuration I’ll encounter a problem that causes the connection to Roon to terminate. It will reconnect after several seconds. Problem crops up occasionally when changing albums. I don’t have the problem between tracks. If I use a raspi streamer between Roon Server and Chord Qutest then the problem does not occur.

Hi @Douglas_Gardner,

This sounds like an issue with Roon Remote maintaining contact with the Core. Does the issue impact multiple remotes or just one in particular? Does it impact iOS/Android devices as well?

This error occurs when your Core can’t reach out servers. It looks like it’s been 42 seconds since it’s been able to communicate with our servers, so it it is likely the network has dropped.

Is this Netgear hub a managed switch or an un-managed switch? Managed switches have caused issues in Roon.

“This sounds like an issue with Roon Remote maintaining contact with the Core. Does the issue impact multiple remotes or just one in particular? Does it impact iOS/Android devices as well?”

Just tested with iPad and yes, the issue shows up with iPad too. I don’t have any Android devices.

“Is this Netgear hub a managed switch or an un-managed switch? Managed switches have caused issues in Roon.”

It’s an unmanaged switch. It’s a Netgear 5-Port Gigabit Ethernet Unmanaged Switch (GS305)

“This error occurs when your Core can’t reach out servers. It looks like it’s been 42 seconds since it’s been able to communicate with our servers, so it it is likely the network has dropped.”

I wonder why this doesn’t happen when I use my raspi streamer to my Chord Qutest over USB or when I use ASIO from Roon Server to Qutest over USB? It seems to only happen when using WASAPI from Roon Server to Qutest over USB. My raspi and Roon Server are both connected to the same Netgear ethernet switch. Looking at the Server logs I only see the, “… A connection attempt failed …”, error when I’m using WASAPI.

Hi @Douglas_Gardner,

Thanks for the additional info!

Since the issue impacts multiple remotes it sounds like there is an issue with communicating to the Core via the network.

Have you tried to bypass this switch and connect directly to the router?

It seems like this is a PCIe USB card, based on your observation that this issue only occurs when outputting via USB, can you try to bypass this card and connect via the standard USB port? If you do so, does the issue still occur?

Yes, I have tried the standard USB ports on the motherboard and got the same results. I agree that it’s probably something with the USB ports but am at a loss on what it could be.

I’d be surprised if the USB ports are IO bound at the data rate needed for audio and can’t think of what else could be in contention for the resource. Something does seem to gum up the works for me with WASAPI and USB to the DAC. I confirmed that all of the drivers are up to date.

Let me know if there are any diagnostics I could run or broader information from the logs that could be useful. I could take the PCI card out completely to totally eliminate that from the system.

I appreciate your help with this. I’d like to track down the root cause though so I can reconfigure my server or at least understand whatever is causing the problem.

My problematic switches we Netgear I had trouble with both a 16 and a 24. My only solution was direct connect to a 2nd Ethernet port.

@Pluto Thanks for the input but it’s very unlikely that it’s the ethernet switch. My DAC connects with USB, not ethernet, and there are no problems when using ASIO or when using my raspi that is connected to the same ethernet switch. The repeatable failure mode is the WASAPI audio path and repeatable success mode is the ASIO audio path.

Hi @Douglas_Gardner ,

Is there anything else interesting in your Roon logs? Can you reproduce the issue, note the exact local time + date of error and send me a full set for review by using these instructions?

Just sent you a link to the zipped files via direct message. I sent a second dm with the timestamp; forgot it first time. The timestamp when I recreated the error was 22:18 local time on Feb 8.

Everyone is probably busy with 1.8 stuff. Posting to this thread to keep it alive.

Hi @Douglas_Gardner ,

Thank you again for sending the logs over and for your patience here while we’ve had a chance to review, your patience here is greatly appreciated!

Looking over you log, we notice that the streaming stops and all of your audio zones disconnected around the same time, this typically indicates a Networking or Core issue.

I suggest that we try with a fresh database to see if there is any change in behavior, can you please use these instructions to set your current RoonServer + RAATServer aside and verify if a fresh database also has this issue?

  • Make a Backup of your current RoonServer Database
  • Exit out of Roon
  • Navigate to your RoonServer’s Database Location
  • Find the folder that says “RoonServer”
  • Rename the “RoonServer” folder to “RoonServer_old”
  • Reinstall the RoonServer App from our Downloads Page to generate a new Roon folder
  • Test with a fresh RoonServer database and verify if the issue reproduces
  • (After a few days) Restore RoonServer backup and verify if issue persists

I followed the steps outlined above and still had the same problem with losing connection to the Core. I happened to have Windows Remote Desktop running on my Macbook when I triggered the problem. Whatever is happening it is definitely taking down the network connection to the server. The Windows RDP session also dropped its connection with the playback problem occurred.

I’m at a loss as to why the network connection drops though. Using this same configuration but with the addition of a Raspberry Pi streamer connected to the same ethernet switch as the PC this problem does not occur. I can’t think of what could be causing different behavior when RAAT is being exercised on the Roon Server machine vs exercised on the Raspberry Pi.

I could try to swap out the ethernet switch with a duplicate one that I have but I don’t see any indications that there’s a bad switch. It’s not convenient but I could move my Roon Server PC and DAC over by my FiOS router and hook up the PC directly to the router via ethernet. Let me know if you think that’s worth a try. That would eliminate WiFi but I’m not having a problem with the WiFi when I’m using the Raspi Streamer instead of WASAPI to the DAC.

I moved my Roon Server PC over to my FiOS router and also my Macbook. I connected both directly to the FiOS router over ethernet. In that configuration I had some very strange behavior. Roon Remote was disconnecting far more frequently in this configuration than when going through the Netgear ethernet switch to Google WiFi.

Lots of investigating on possible causes. I wound up uninstalling and reinstalling the Chord DAC driver. That didn’t seem to fix anything.

Then I dug into Windows Firewall settings and I think I may have found a fix. I looked at the Windows Firewall settings for allowing apps to communicate through Windows Defender. There are 4 entries for Roon applications. Two of the entries are roon.exe and two entries are for roonappliance.exe. One of the roon.exe entries had a check box for Private and the other roon.exe had a check box for Public. Same for roonappliance.exe. I checked both the Private and Public check boxes for all of these app entries. After doing so I haven’t had a dropped connection to the Core. Attaching a picture of the settings window after selected both Private and Public for your reference:

I don’t know why there are duplicate entries for roon.exe and roonappliance and I don’t know why Private was selected on one and Public on the other. With both Private and Public checked on both apps I don’t seem to be experiencing the disconnections from the Core. I’ll run in this configuration for a day or so before I restore the last backup I did prior to the reinstall of Server.

Please advise on how these settings should be set and if this might create a security problem.

Disregard the above. The problem still persists.

I think I’m going to give up on this issue for now and just use Roon through my raspi streamer to USB DAC. I can’t figure out what’s going on that’s causing the connection drop when using WASAPI from Roon Server. Thanks for helping me take a look.