Audio Devices
There’s a variety of devices. It affects all of them. Principal audio used is ASIO USB. On board audio is RealTek and NVidia neither of which are used.
Description Of Issue
When coming back from sleeping, whether Roon was running or not at the time of sleeping, all Audio devices are forgotten and refresh fails to restore them. Deleting the RAATServer directory from AppData\Local brings them back as not yet enabled and in a detault configuration. Enabling any of the Audio devices restores the original zone naming and the last active zone.
This had happened, but rarely, before the Windows 10 2004 Update. Now it is every time. And every time I delete the RAATServer directory it restores the audio devices.
Before finding issue 81044 I investigated the logs and discovered that initially the audio devices are requested and the JSON delivered but that subsequent Client requests timed out. There’s a regular refresh cycle which can be detected in the UI when this happens, I haven’t noticed or investigated if this refresh cycle happens generally.
I have a separate audio device which is a Chromecast on a TV and that generally survives this and operates correctly.
Roon server and client components are running on the same laptop, MSI GS43VR 7RE, 16Gb physical RAM it runs on mains and on the full performance spec, it’s not overclocked.
I suspect this issue is due to the RealTek driver, we have seen similar reports in the past. If you are not using the RealTek driver, we would suggest you uninstall it, see:
Disabling it certainly doesn’t make any difference.
I’m extremely loath to remove base system device drivers without an actual diagnosis, especially as the drivers themselves haven’t changed in the update to 2004 so I’ll continue the workaround of removing the RAATServer directory before each running of Roon.
If you do not wish to uninstall the driver, you could also temporarily disable it in Device Manager as the other user noted: Switching off Realtek device in audio section in Device Manager (press Win + X).
Without any known updates of anything very much this hasn’t happened for over a week. I haven’t changed how the system sleeps or how I use Roon. I haven’t had to delete the RAATServer directory since.
The original problem seemed to be a timeout between client and server (which doesn’t identify the root cause). The UI has the list of devices, it makes a call to the server it waits on the response and when that times out clears the list.
Glad to hear that the behavior has subsided! There was a Roon update around the time of your latest message, so perhaps that helped. In any case, do let us know if you run into further difficulties!
Unfortunately a complete restart still has the same problem, but that’s generally less disruptive. I can delete the RAATServer directory on each starter and reenable each of the devices I use. I should investigate the API to see if I can automate it.
It didn’t help as a diagnostic and it’s not a solution that makes sense. I’m not going to disable a system driver that appears to be working for the sake of an application. Try almost random thing because we’ve had troubles with this kind of chip set or driver isn’t an acceptable response.
The fault at start up might well be initialisation of a particular driver or combination of chip set and driver but that doesn’t mean it’s the fault of the driver. Because it causes a timeout between client and server on the same physical machine there may be an I/O block that causes that but then I would expect it be known diagnostically at the server.
As an alternative, modify the client so that it doesn’t blow away its known devices unless and until there is a failure in using them. The fault is that the current list of devices is not returned to the client. It might feel that this is the sane way to have it, that the server knows about devices that are available but from a client perspective building the list of devices each time is a spurious step if there is already a list known.
Delegate handling a failure to using a device to the code that uses the device, not a piece of code that runs through a device chain.
The way it is now there will always be the possibility of devices appearing and disappearing which doesn’t help the confidence of the user in the product.
To clarify on the use of the RealTek, I may not use it for Roon but that doesn’t mean I don’t use it or the NVidia at other times, disabling even temporarily is not a solution.
ie I could script disabling the audio driver before running Roon and script turning it back on again but given I get the same result by deleting the RAATServer directory and it doesn’t cause ripples through the rest of the system I’ll continue to do that until Roon Labs fixes the problem.
If you are experiencing the Realtek issue, then you should be able to use the device even with the Realtek driver disabled, it would fall back to the Generic Audio Driver on your PC.
If you prefer to do the RAATServer refresh instead of trying to disable the driver, that’s your call, but from what I’ve seen simply disabling Realtek’s implementation of the driver helps with similar behavior.