Restarting USB and NAA

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.

Thanks @Brian for the response.

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…

http://www.signalyst.com/beta-install.html

@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.

@jussi_laako, I may of not waited for the complete release before I shut down the DAC the first time because it works now but what still happens is this…

Turn my DAC back on, set input to USB, the DAC screen reads 352.8. Press play in Roon (on IPad) DAC screen reads dsd128 and music plays from where it was previously paused… Now when that track finishes and goes on to the next song, the same thing happens as my previous post. The Roon song timeline doesn’t move, the odd clicking sound and the 4 menus plus the play and pause buttons flickering in HQP.

That is something else and probably unrelated then… Flickering indicates that something is stuck into a loop. Maybe log file could tell…

@jussi_laako. Interestingly this morning when I turned on my DAC (HQP was still opened from last night) and chose an album to play and it work perfect without a problem no glitch going from track 1 to 2 at all. The difference is the album is from Tidal and the issue from last night was that both times I was playing a local library album, could this be related to the issue?

My music library is stored on a FW400 4TB drive attached with an adapter to the FW port on the MacMini.

PM me and let me know if you would like to see my HQP logs and let me know how to get them and send to you.

So I have a little update here. Prompted by last week’s postings, and for little investment, I purchased the Raspberry Pi 2 to see how my system would get on with one of these slim devices. Very easy to set up using Jussi’s pre-baked NAA’s. My Roon Core running HQP picked up the NAA and I named it. All works … great.

But the issue with my Devialet 200 being switched into stand by, or another input, still caused the NAA to drop the USB connection to the Dev. Now, in and around the Dev, I want any ‘device’ to be headless, that is the goal in my case, and I want it to be relatively smart in knowing when inputs are switched or connections come out of stand-by. What I do not want to do is leave my Dev 200 on 24/7, especially as I will be moving to a hot country later this year.

If you follow Jussi’s train of thought and how he has designed the NAA, everything gets turned on or off at the same time and there is an order in doing this. But that is not universal as to how users run their systems, I cannot be the only one who only wants to turn off part of the overall set-up. The whole point of the NAA is that HQP can run on a server remote from one’s setup, indeed, this seems to be the recommended practice from both Roon and HQP, put this software on a beefy computer (in most cases a Mac or PC). Surely the suggestion cannot be that this server (green sensibilities aside) has to be switched off just to use NAA. OK, maybe not switched off, but having to share screen to the server to shut down HQP, which can be done by iPad (my optimum control point for music listening) but hardly convenient. My iMac server has other duties, not many, but does not re-boot on a daily, even weekly basis, I will reboot occasionally for various and whatever reasons.

What I did find is that the NAA on the Pi2 will pick up the USB connection again so longs as, firstly HQP on the Roon Core is in a stopped state (no music playing and HQP released by Roon), and secondly, that works ok in, say, a day’s listening session.

Leave it overnight, and come back to it and it refuses to pick up the NAA, even with a restart of HQP on the server. It needs the NAA to be rebooted for everything to come back connected. This I am finding is neither easy or convenient on the headless Pi2, just as it was not on my headless MacMini, the latter was easy in a Mac household, you share scree into it. The Pi2, maybe just as easy, you pull the power and re-connect, but potentially corrupting the SD disk with the OS. You can probably remote into it, I have not mustered the will to find out how to do that yet, essentially because this is a ‘geeky’ interaction, something only I could do in my household.

One other point I have found in this disconnection saga, is that with HQP / Roon Core on a Mac as the server, HGP will default to Core Audio (on that Mac) when it cannot find the NAA. Thing is core audio does not know about SDM and DSD over DoP, so HQP now with ‘Auto’ settings defaults to PCM, when the main and one reason I purchased HQP is to up-sample everything to SDM. So I sort out the USB connection, and play some music, only to find I am back in PCM mode, stop the music, switch to SDM and fine, away we go.

All of this involves too much thought and too much phaffing just to play music, same as the previous day.

Here’s the rub, my Devialet is not going anywhere, with that particular manufacturers whoes and troubles with AIR, Spark & Dialog, USB is my default input for best listening. Roon is not going anywhere, the best music management software out there, by a country mile. HQP up-sampling is fantastic, and the integration into Roon is also fantastic when the music is playing.

I could, of course, revert to Roon only as the music deliverer, further integration would be welcome, but really this whole issue for me (and a few others) appears to lay at Jussi’s door, after all, HQP requires full control of the music stream once it leaves Roon. NAA is well worth it to keep the hard-grinding to a remote server and keep the music deliverer next to your hi-fi, neat, slim and low power, ideally something one would not think twice about leaving on 24/7. This implies, to me at least, that it should be just there, and require infrequent or ideally no user interaction at all.

I am not sure where to go with this now, but I keep returning to my train of thought in that, is it at all possible for the NAA to remember the default ‘audio device’ as I thought ‘Naming the network’ does (even though HQP main program might see the audio device on the computer it sits on as it’s default device), poll the NAA to see when the (preferred) connection is alive and do this automatically so no user intervention is needed to adjust settings in HQP or re-boot the NAA. Sure, if you want to change to another NAA, or use HQP direct, then this may involve a trip into settings, but again, as suggested, this could be useful to have in Roon interface, rather than having to remote into HQP in whichever way your set-up dictates.

There are two other possibilities I can see for the future if this partnership is to deservedly flourish, first, HQP loops back it’s output to Roon which then takes over actual streaming duty, or second, HQP is built into Roon as a DSP enhancer. Both of which reverts to one interface with Roon, ultimately how this hook up should really work, but undeniably would involve leaps of faith and trust in both companies, and would take some time to implement I would imagine.

1 Like

I agree. The whole swapping inputs procedure and occasional restart of the Pi, running the risk of SD corruption, is geeky and awkward.

You can’t remote in to the image either to shut it down safely (at least, I can’t, I understand the image is a set of minimal optimised routines, with a lot of usual OS stuff missing. It’s only about 82 MB of functional stuff).

Eventual closer integration between Roon and HQP Is something to look forward to, but in the meantime a more persistent handling of the NAA USB connection if the DAC inputs change, or it is turned off, while HQP is open would be great.

Thanks @andybob, I rather suspect this issue would still happen with other popular slim devices at the moment (SoSE, BBB) although @RBM seemed to have some success if he had something connected to SPDiF on his SoSE.

I think, like you, I am an Uptone Regen user, and that brings all good things to async USB connections, IMO. I have my eyes on the microRendu, not least because it uses the same goodness of the Regen built in (John Swenson has had a hand in the design of both). I really like the though of the microRendu, a slim low power device, with HQP NAA and RAAT, and ‘Regen’ in the hardware, I would be in temporary musical heaven until Roon decide what they will do with DSP enhancers built into Roon software.

The fly in the ointment is this disconnection issue with NAA. It really needs Jussi to decide if this is an ‘issue’, or it becomes an exclusive hi-fi geekery listening session for me, and not for use by all the family. He may wish to keep things just as they are, which is fair enough, I would just like to know.

(BTW the reason I post this here rather than Sygnalyst forum is it is intrinsic to me that Roon is the master here, not HQP, in terms of my user interface for not just me, but the whole family).

Yes, I looked into this and it would mean adding the NAA to one of the standard distros, that you and others have so admirably documented. I even looked at the possibility of adding a small touchscreen (quite a few on the market) to the Pi2, just to give access to a proper shut-down and restart. But then I thought, why should I have to even do this?!? :confounded: