When switching my Devialet 200 to USB or bringing it up from a sleep status and I find I have to re-start the NAA running on my (headless) MacMini which provides the USB feed to the Dev. Almost every-time, a real PITA. Considering replacing the MM with a dedicated NAA (rPi, Sonicorbiter SE or microRendu) but not sure if any of these will monitor the USB connection?
Hi Allen,
I think this topic deserves itâs own thread. I havenât swapped between inputs on my DAC a great deal with an NAA connected. I understand that it is best to quit HQP before changing inputs and then restart it after the DAC USB input is selected again. On the odd occasion when I havenât quit HQP I have had issues with needing to reset the output device in HQP, sometimes requiring a restart of HQP, but I canât recall needing to restart the NAA.
I havenât tested it thoroughly but my recollection with the Pi and BBB is that once you name their IP addresses in the HQP Network name tool then HQP remembers them at that IP address. Havenât tried with the CuBox-i but I would expect it is the same.
Iâll do some experimentation tomorrow and report further. I now have Raspberry Pi, BBB and CuBox-i all working as NAA.
It may be that Rene (@RBM) has had some experience here.
I hope RoonSpeakers wonât do this⊠Iâm sure it wonât as Roon always seems to re-establish connection with my Devialet no matter what - switch to another input, hard power off, soft power off - it always comes back really nicely. Itâs really impressive in fact.
Unless itâs a limitation in the USB implementation on Pi type devices?
Alllen is using a Mac mini. I havenât found the Pi or BBB to have the same problem. I suspect naming the Mac-mini in HQP will help solve Allenâs issue. This issue doesnât relate to Roon USB endpoints which are well recognised after inputs change.
@andybob Sorry, no, giving the MacMini a name under the NAA settings in HQP has little effect. Itâs not a case of not finding the machine with NAA on it (which in my case has a fixed IP address on my network). The issue seems to be NAA running in Terminal on OS X is fine until the USB connection is lost (by whatever event). The process then ends. Even bringing that USB connection back up again will not work until the NAA is restarted. In other words, once itâs gone, itâs gone, the process has to start again.
My question is why cannot that process (NAA) stay up and monitor for the connection to be re-made? Maybe itâs a rhetorical question, probably because only Jussi can answer it.
Did a little testing with my headphone setup (Cubox-i NAA, iDSD nano):
- When the nano is turned off, it drops from the Networkaudioadapter list in HQP as expected. HQP gracefully falls back to the Cuboxâs SPDIF-out.
- Since @jussi_laako said the nanoâs power draw may keep the USB connection alive even when turned off, I brutally yanked the USB cable. The nano disappears, but reappears and is autoselected upon replugging.
This is with my own Debian + networkaudiod install, but I canât see why it should not be the same with Jussiâs prefab image. I cannot tell how an NAA behaves when is does not have a secondary audio device to fall back on, but judging from the above behaviour, the Cubox appears to be a safe bet for troublefree NAA in any circumstance.
As things stand with current application versions, I find that HQP & Roon work in tandem flawlessy and without intervention (both apps running on a 2012 quad-core i7 Mac mini). Anytime I want to play with HQPâs filter settings, I use Screens on my iPad (costs a little, but is the fastest and most flexible Screen Sharing / VNC app I know of).
Iâve got a Raspberry Pi feeding my DSP5200âs and another Debian Cubox connected to an F80 through optical, both running squeezelite. All three little buggers have been rock solid for weeks â not to mention they sound great. Got to love the flexibilities Roon has to offerâŠ
I thought Iâd move my post over to this topic as it relates more. It would be great to hear from @jussi_laako and @brian as why Roon stand alone has no problem, but HQP/Roon doesnât keep USB dac info.
Personally I hope eventually full integration of HQP into Roon happens, because in my setup having the 2 programs running kinda sucks⊠My DAC has a tube output stage (Unison Research CD Due) so I donât leave it on all the time and I run a headless MacMini which when I turn my DAC on and change the source to USB, HQP doesnât remember my DAC from the day before, so I have to quit HQP and restart and than press the Roon disconnect button a few times before everything is working (sometimes have to do this twice before it works)⊠Kinda a pain to go though all these steps and if I want to play CD, I have to go through all the above steps again as HQP does not remember the DAC⊠Using Roon alone has none of these issues and I can just press play on my iPad to get some music going⊠For the time being using HQP is a no go most of the time.
When HQPlayer is involved, we donât have any relationship with USB or the DACâHQPlayer is our âaudio deviceâ.
The reason why Roon+DAC works is because we are watching for device plug/unplug notifications from the operating system and de-initializing/re-initializing our relationship with the hardware when there are changes.
It took a few rounds of iteration to get this all right on the different platforms/driver systems, and in cases involving machine sleep. ASIO on Windows is the worst because it has no such notifications, so we have to do some tricks there.
I donât have insight into how HQPlayerâs driver stuff works internally, but before we directly handled this class of problem, I know we used to have issues like this.
Hi Allen,
The difference between Rene and my experiences with the Raspberry Pi, BBB and CuBox-i (where we are not seeing the problem you describe) is that we are running under either Linux (or a stripped back version of Linux adapted by Jussi for NAA on the particular device - the NAA image). In both cases NAA runs as a daemon or service and it persists through USB disconnection.
I suspect that if the Mac-mini NAA process is not persisting through USB disconnection, then it is something to do with the OS X version.
Having darted around the various specific threads for devices that can run HQP NAA my interest has perked on the Pi/Cubox/BBA solutions.
With a MacMini running NAA, it will disconnect from the USB if the DAC that it is connected to goes to sleep or is inactive for a long period or is powered down (Devialet 200 in my case). With the MM running headless, this is a pain as you have to remote into it and re-start the NAA from HQP.
Do any of the above mentioned devices maintain the USB connection in such a scenario, or seek it out when the DAC (Devialet) is switched back to USB input or woken from a sleep state?
Behavior also depends on the DAC. Some DACs like iFi iDSD Micro run the USB interface from USB power even while the DAC itself is powered down, so the DAC remains always visible. For these, there is no USB disconnection. While many other DACs power USB from the same PSU as the DAC itself and thus disappear from the USB bus when powered downâŠ
On Mac OS X there is one extra problem with USB disconnects, because the OS tends to pick up a different ID for the DAC when it comes back again (maybe since the OS doesnât know if itâs the same or different one).
Linux usually has most consistent behavior on devices coming and going.
Is that the case with the Uptone Regen, or the soon to be released Sonore microRendu ( which seems to have to same USB âregeneratorâ as the Regen built in)? Provided they are permanently powered, but the DAC on the other side may âdisconnectâ?
With NAA, the device is released when HQPlayer is closed and acquired again when HQPlayer is started.
If HQPlayer is not running when DAC is powered down and restarted, it shouldnât have impact on NAA. Regen is a transparent device (as long as powered up) and doesnât have a role on this picture.
Does the 3.13.0beta8 for OS X help? Works for me when I power down/up iFi iDSD NanoâŠ
@jussi_laako. I just installed the new beta and powered the DAC on/off while keeping the beta open.
I pressed play in Roon and my DAC switched from reading 352.8 to dsd128 but the timeline of the song didnât move and an occasional clicking sound. I then hit the disconnect link and pressed play again and nothing happened but in HQP the four menu bar options plus the play and pause button were all flickering.
Quit HQP and restarted and had to press the disconnect link twice and playback started.
Hope this helps.
Can you test this without Roon? HQPlayer in stopped state, power DAC down/up and then start playback again.
HQPlayer log file could help figuring out what is going on.
Sure, Iâll try now.
So I quit RoonServer and HQP. Restarted HQP and dragged one flac file into the window (the song appears twice?). I double clicked on the file to play, after a little spinning beach ball time the song played. I pressed the stop button, turned off the DAC and restarted, changed the input to USB, on the DAC the screen reads 352.8, double clicked on the file and DAC screen changed to dsd128 and music⊠No restart of HQP required.
When HQPlayer is used through Roon, when playback is stopped (paused) from Roon, there is some amount of timeout where Roon keeps HQPlayer in paused state (playing silence to DAC). After something like 5 seconds if there are no further actions, Roon asks HQPlayer to go to stopped state.
Turning off DAC and back on in stopped state should now work most of the time with beta8. But if the DAC disappears while playing/paused things probably go pretty messed up.