Test only works sometimes for me 
lately I’ve had to logoff and back in again.
Do you need anything more? I have confirmed the issue.
Please let me know.
Hello @Andreas_Lindmark,
Thank you for the update and for confirming the issue on the supported setup.
Since we are using a different type of driver by default on Windows devices, we need some time to discuss the issue internally. We will get back to you with updates as soon as possible.
Additionally, I noticed that our QA engineer has asked for some clarification to help reproduce the issue internally. Would you kindly provide more insights regarding this? Specifically, can you please describe the steps that lead to the state you mentioned?
From what I understand, the steps may look like this:
- Select ASIO zone
- Play a track via the ASIO zone
- Wait until playback finishes
- Terminate Roon
- Check if the OS can still access the audio device via the ASIO driver
Also, please verify whether the ASIO zone is marked as Private in Roon (Right-click on the zone → Device Setup).
Your insights will be very helpful in narrowing down the issue.
Thank you again, and we look forward to your response!
Yes.
It’s quite simple.
- select zone
- Play a song, either the full song or just a few seconds.
- Pause the track and/or just quit Roon.
- Sometimes I can get sound back by going to the control panel for sound and right click on the device > test.
- When that doesn’t work, I have to logoff and then in again.
Disabling the zone in Roon does not seem help the issue.
I have not tried disabling/enabling the device in windows, that might work.
I have the zone set as private indeed, I can try to change that and test again.
Sincerely
Hello, @Andreas_Lindmark,
Thank you for the update, we are looking into your case internally and will get back with an update as soon as possible.
1 Like
Thanks! Turning Private zone on or off does nothing for this issue, it’s the same.
Thanks for letting us know @Andreas_Lindmark, we’re still looking into reproducing the issue in-house for next steps.
We’ll share any updates as soon as they arise - thank you for your continued patience in the meantime! 
1 Like
This thread is overdue for an update - please accept our apologies for the long delay.
Here’s the status: unfortunately, this particular issue relates to a long-standing Roon issue affecting certain Thesycon/XMOS 2.0 drivers, including those inside the Atoll HD100.
We don’t have a fix implemented yet, but please allow us a chance to ascertain the current status of the ticket from the engineering and partners teams. We’ll post here as soon as we have a more fruitful update to share from there. Thank you!
1 Like
Hi @jonnie,
Our apologies for the long delay in responding.
Obviously, we have not yet released a fix for this issue. Please allow us chance to inquire internally as to the current status of the associated ticket/fix and escalate accordingly. We’ll respond here as soon as we have more information to share.
2 Likes
Ok, thanks!
Down below you can find the result of an analysis regarding this issue that Thesycon has done a while ago. T+A forwarded Thesycon’s findings to Roon in March 2023 but unfortunately the issue could not be resolved back then. I am sure Thesycon will provide further information and help, if needed.
Hopefully a solution can be found this time.
Here what Thesycon had found out in 2023:
.
Problem: Roon does not reliably react on ASIO Reset
When the underlying USB device connects/disconnects, the ASIO driver fires an ASIO Reset event via ASIOCallbacks->asioMessage(). Because ASIOCallbacks are provided to the driver in the ASIOCreateBuffers() call, the driver can deliver ASIO Reset only when the application set it into PREPARED state (see ASIO spec section 2). When the application (Roon) receives an ASIO Reset, it has to shutdown and recreate the ASIO driver instance.
Roon seems to set the driver to PREPARED state only when some music is played. If nothing is played, the driver is in INITIALIZED state which means Roon cannot receive ASIO Reset events. If the USB device disconnects and reconnects while Roon is in this state, Roon will not notice and will not shutdown/recreate the ASIO driver. As a consequence, subsequent ASIO calls such as ASIOFuture() or ASIOSetSampleRate() will fail. This is causing the problem reported by T+A.
Most applications (DAWs) always set the ASIO driver to PREPARED state and thus are always able to react on ASIO Reset. But note that there is a potential race condition (as per design of the ASIO interface): If an ASIO Reset happens after the application has called ASIOInit() but before it called ASIOCreateBuffers() and installed the callbacks, the application will miss that event. Therefore, an application should also check return codes of ASIOCreateBuffers(), ASIOFuture(), ASIOSetSampleRate() etc. calls. If one of those functions returns ASE_NotPresent, this indicates that the underlying device is no longer present. In this case the application should shutdown the ASIO driver instance and and recreate it beginning with ASIOInit().
3 Likes
Hi @Larry_HV ,
Thanks for the reminder of the information that was found. This info is in the ticket, and I’ve asked the dev team for a status update on this.
Hi everyone,
Thank you again for your patience. This issue is at the level of Roon engineering and our partners behind the scenes. We will post updates as they become available.
1 Like