Roon Bridge on Windows crashes after USB device reconnect
I have a Holo Audio Spring II DAC KTE connected via USB to a Windows Server 2012 R2 NUC D54250. Also installed are Audiophile Optimizer 3.0 and Fidelizer Pro 8.4.
When I change the DAC‘s input (let‘s say to Optical) the USB device disappears in the device manager. If I then switch back to USB it reappears an Roon tries to start Playback but fails. After a few seconds it skips to the next track, fails again and so on. Such a fail is visible that the seek bar is not progressing and there is no sound output.
The only way to re-enable normal operation is to reboot the NUC or to kill “RoonBridge.exe“ in the task manager and to restart it manually.
I guess the driver is not re-initialized correctly by RoonBridge.
How can we fix this?
I‘m told there are other DACs with a similar behaviour, switching off what‘s not needed.
And yes, I know of alternative inputs like I2S but I‘m not ready to give up on USB just yet.
(I do have a workaround that automatically restarts RoonBridge.exe but this is far from elegant and I guess also quite involved, technically).
I can confirm latest driver and firmware for the Spring II DAC.
Just checked what happens after a power cycle: the bridge comes to live again after pressing ‚play‘.
Of course, that‘s not a solution, since such a power cycle requires to manually hit the switch at the backside of the DAC.
Thanks for letting me know. I have reached out to our hardware team to see if they are able to reproduce your findings with the Holo Sping gear we have in-house. While this occurs on our end, can I please ask you to reproduce this issue on your end and let me know the exact local time + date in your country when you notice this behavior occur for diagnostics purposes (e.g. 7:04AM on 8/16/19)?
Hi @noris ,
Time Zone CEST:
15:48 usb -> aes (while playing, transport stopped, roon lost control…)
15:50 aes -> usb (pressing play impossible due to vanished zone in iPhone and iPad apps)
strangely, after 1-2 more minutes the zone suddenly re-appeared and I could successfully start playback again. Until then I never experienced this particular behaviour. The zone remained unreachable until I restarted .exe or PC. Also it was not always the case that the audio zone disappeared in all apps and control instances at once, sometimes I could see the zone still in one of them and hitting ‘play’ worked perfectly.
Thanks for your efforts and those of your team, really appreciated! Hope the time-stamps lead to something.
Edit: around 16:18 I could recreate the original behavior. Switching back to USB brought nothing but time-outed playback attempts and skipping until the end of the playlist queue.
Thanks for letting me know those timestamps, I have enabled diagnostics mode for you account and what this action does is automatically upload a set of logs to our servers for analysis. I see that the RoonBridge logs did arrive, but the Core ones did not and unfortunately in the RoonBridge ones there is not much diagnostics information. Can I please ask you to:
Link to logs sent, for item #2 I will take a little longer, since RoonCore is running inside an Unraid Docker. I’ll have to setup a Laptop using RoonCore and switch my account to it, temporarily. I’ll report back when done.
Using a PC running Windows 10 and the Holo Audio Spring 2 DAC, we were unable to reproduce the symptoms you are reporting. We tested the latest WASPI and ASIO drivers, the ASIO driver reported itself as version 4.67.0. Our Spring 2 DAC is running firmware 30.12.
I would recommend paring down your setup and removing any applications that could impact the audio playback chain. I would also recommend testing with another computer to rule out some hardware specific interaction that could cause the behavior you are seeing.
Hi @john , @noris ,
The driver and firmware versions do match the ones you mention.
So this weekend I tried out quite a bit:
the NUC OS went from Windows 2012 R2 Server to Windows 2019 Server Standard (new install from scratch). No success, same behavior, even more reproducable.
Shutdown Roon Core docker installation and ran it on another Windows PC instead. No success.
Installed Roon Core on the NUC where the DAC is attached to (trying @noris suggestion). No success.
Used a MacBook Air 2009 (Yosemite) with Roon installed as end point only (Core still running on the NUC). Different behavior (probably as it’s supposed to be). Switching inputs on the DAC now caused the entire end point to disappear immediately in Roon (this is for me the not-so-good part*). However, as soon I switched back to USB input, the endpoint re-appeared and could immediately be used to play music. Wonderful.
Went back to my Roon Core running in the Docker and to the Windows 2019 Server NUC as end point. There I tried alternative methods to revive the “orphaned” DAC-RoonBridge relationship after a switch-back to USB.
So far I simply restarted the RoonBridge.exe which was quick and worked.
I tried to use “devcon.exe” to revive (restart) the USB-driver hub(s) and the Holo-Audio Driver in various combinations, without success.
therefore I went back to the “old” way of restarting RoonBridge.exe with parameters matching the behaviour of FidelizerPro (currently core-1 only, RealTime priority)
Summarizing, I think it may be related to the specific Gen-4-NUC D54250WYK hardware, specifically USB and its relation to Holo’s Thesycon driver. Maybe one day I’ll try to install ROCK on it and try again, perhaps Linux’ different driver handling is beneficial here. On the other hand it could be easier to give in to the cravings of my friendly hardware sales guy and invest some money in a USB-I2S converter… Not decided yet (maybe I2S really sounds better, somehow. Not tested myself yet, so still sceptical.)
Thanks again, I’d be glad to have further suggestions
*) I’m using the “Deep Harmony” extension to assign Harmony Activities to Roon audio zones. Using the app to transfer a playlist from a different zone to the Holo-USB will fail of course, if the zone is currently not visible in Roon.