Restarting USB and NAA

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

I’m afraid I can only tell you my NAA Cubox continues to behave nicely, whatever I do to the attached iDSD nano (leave it on, turn it off, yank the USB cable – anything). Every time when the nano is on, it is (re)selected in HQP.

I’m running a manually upgraded Armbian distro on the Cubox. With a Pi, I’d start with Raspbian Jessie Lite (‘official’ distro), upgrade to Stretch and install the networkaudiod service. If you’re in luck, it’ll behave just like mine. But at least you’ll gain the option to just ssh in and reboot if required.

(If you’d prefer a more minimal distro, the ua-netinstall procedure mentioned in the Pi NAA thread works just fine, but is slightly more involved).

Added: to be clear: I have nothing attached to the SPDIF port. I guess the Pi would behave the same if the regular audio driver is loaded as well.

Thanks @RBM for all those pointers, part of me wants to get my hands dirty with distros, so to speak, and resolve this issue, the other part says, this is Jussi’s commercial software and he is a million times more expert than my Linux and network daemon services knowledge.

I do wonder if there is something in the fuller-fat distros that look for the USB connections and then pass that onto the NAA, when a USB connection comes alive, does the OS reset the NAA, or at least ask it to? It seems to me this is all that is needed.

Fishing in the dark really, we have heard from Jussi why this happens (by design of his NAA) but it would be nice to know that it is simply resolved, either by a NAA re-work or going to one of the distros and building on top. The former would, to me, be the ideal, since the device carrying the OS can be kept very minimal without unnecessary background processes happening.

I would imagine that’s what the Sonicorbiter guys have done, and why you pay for that development on top of the basic cost of a Cubox when purchasing the SoSE for example.

Just because it’s raining, snowing and there’s all kinds of nastiness outside, I took a Pi, did a fresh ua-netinst install of Raspbian Jessie, upgraded to Stretch and installed the networkaudiod.service.

The good news: I can plug, unplug, turn off and turn on my nano ad nauseam – and upon replugging of turning on HQP Player immediately recognises the lost son. My be worth trying with your Devialet. Note: I had to add the same ‘After=’ line to the service as described in the Cubox NAA thread.

The bad news: as @andybob already noted in the Pi NAA thread, the Pi is a lousy NAA when used with USB. Any seriously upsampled format is pretty much unlistenable (PCM 384 / DSD 128 > light (but plenty) pops; DSD 256 > heavy distortion). Lower rates appear to be fine.

One thing I noticed: when music is stopped from Roon, HQP (as @jussi_laako said) takes a few seconds to release (the play/pause buttons in HQP are pressed in this state, and become unpressed after a few secs).

If I wait out this period, I can safely turn off the nano (in HQP’s networkaudioadapter pulldown, the onboard audio of the Pi will remain visible as NAA, and the nano returns to the menu when switched on again). When I don’t wait and turn off the nano immediately, things go haywire (all Pi-related audio, both onboard and USB disappears and is visible again only after a reboot of the Pi (or a service reload, most probably).

Anyway – that’s what I have. It seems the Pi could fix your connection issues (most likely), but with DSD you really want a Cubox. Or a BeagleBone. Or anything.

1 Like

Because I am facing the same weather nastiness as Rene, I also did some homework. First of all I updated hqp to 3.13.
Normally I stream hqp on a server 2012 PC via USB to my lampizator dac. Roon server is on a mac mini. remote is on a Samsung tablet. Wanted to try out NAA. So I installed NAA on my Macmini. Put the mini next to my dac changed the USB cable from the PC onto the mini and was good to go.
Had some doubts if having Roon server and NAA on the same machine would work. It must be a burden for the network. Roon streams the nas stream from the mini to the hqp PC which returns the hqp signal back to the NAA on the mini. But… It sounds great. Everything to dsd128.
So a good time spending this afternoon.
Is it right that the Osx NAA doesn’t do non dop dad?

OSX NAA does pretty much the same OSX without an NAA would do. I can play DSD256 (DOP) via OSX NAA to my nano just fine.

I actually ment if OSX NAA supports native-DSD (non-dop). When I choose for DOP in the preference SDM checkbox it works fine. If I choose ‘none’ (or an equivalent term) I get no sound at all. The DAC is supporting native-DSD. When I had my windows server 2012 pc hooked directly to the DAC that setting did work well.
It is just a question, not really important. I guess there is hardly a sonic difference between DOP and native.

Too keep a little closer to the topic: the mini and the pc are both headless. So I have to make sure that everything is starting as it should be. I do it like this:

  1. Start the macmini. RoonServer already starts automatically. I added naa to the automatic startup in osx and this works well. Starting up the macmini is max 1 minute.
  2. Because the WS2012 pc remember the latest settings of HQPlayer (I use it in minimal server mode through AO), starting up this pc must be done after the mini. Otherwise HQP won’t find the NAA.

Until now above procedure didn’t give any problems and I can trust on the fact that it all starts as it should without checking both pc’s with VNC.
I never pull out USB cables nor switch inputs so loosing the connection during listening time isn’t my scenario.

Many thanks once again @RBM. So I did get my hands dirty, went through the similar procedure to which you described, picking up other contributions from @andybob, @jussi_laako & other threads, Jessie Lite to Stretch and so forth. I let the installs bloat as much as they needed to, so LightDM was installed via raspi-config (which I will come to later), mainly to try and ensure there were no config or service files missing.

This obviously differs greatly from Jussi’s pre-baked releases where it seems everything is cut to the bone. I was hoping that, if other ALSA devices are configured then some persistency might exist with the various connections to the Pi2 and within the OS, talking aloud here (and attempting to pick up on your situation with the Cubox and SPDiF), I am no Linus expert here, quite the contrary.

Well, so far so good, switching my Dev off and on is being picked up by HQP via the NAA in what I would call ‘normal service’ as we would use it. The fuller OS also allows SSH into the Pi2 so I can check status of the NAA, start / stop it and properly re-boot if required. I will ‘stress test’ it, so to speak, to see what circumstances the USB connection will be lost, I think I know, but will plough through the possible scenarios. Our setup effectively only requires the Dev to be regularly switched into stand-by, the iMac music server with Roon Core and HQP and the Pi2 NAA can stay on most of the time.

So, I can only surmise that the full install of the OS and adding NAA to it has maintained something which must have been missing from Jussi’s very, very slim releases. I have probably gone OTT with LightDM, but I am very much a learner here with Linux, Debian, etc. I will probably repeat the process without the desktop addition and it does not seem relevant to the disconnection issues as I unplugged the HDMI monitor with sound and those ALSA connections were obviously no longer shown in HQP via NAA.

As for sound, well the Dev is not too demanding, 192 PCM and DSD (DoP) is it’s current limit, so I am not experiencing any crackles or pops within tracks, just a very small pop at the start of the first track. Used to get that on the MacMini NAA as well, so not down to the Pi2.

For me, the Pi2 was really a test run towards possible purchase of the microRendu when it’s released, which I would like to use with the NAA, so this is quite promising so far. The only thing I was slightly flummoxed by was Jussi’s recommendation to ‘discard’, not quite sure of the syntax there, everything else I fathomed out. Not bad for a novice :grin: Thanks again to you guys for the previous knowledge shared, this is a great site and forum!!


Yes, in Core Audio’s OSX you can only do DSD through DoP.
Non-DoP is only allowed, as far as I know, on ExaSound DACs because they use their proprietary ASIO in OSX.

Just to add to what Gianluca said about OSX. I’m sure Jussi said somewhere either here or over on Computer Audiophile, that NAA only does core audio on MAC’s even those with Exasound DACs and ASIO drivers. I know this as I have one and cant get the NAA to use Exasound’s ASIO drivers. The drivers only work when HQP is on the MAC itself and an NAA is not used.


ExaSound ASIO drivers cannot work on a Linux based NAA. That’s why ExaSound produces their own PlayPoint product.
ExaSound ASIO drivers can work on a Windows or OSX based NAA.

Only Windows NAA supports ASIO. NAA on OS X uses CoreAudio…

Good to know. How come NAA on OSX cannot use ExaSound ASIO for MAC driver?