I can of course leave my Devialet on 24/7 and this helps some of the time, but even then the NAA (running on a MacMini) will lose the USB connection from day to day more often than not. Regardless, leaving the Dev on all the time seems counter intuitive (these units run very warm, even when not playing) and hardly ‘green’. The MacMini is also on 24/7, and whilst it is pretty energy efficient, a dedicated NAA as mentioned in previous post, would draw so little power to be hardly noticeable.
(P.S. The deal breaker is HQP way of doing NAA. Roon stays, no matter what )
I get the loss of connection with Dirac, and it was annoying enough for me to return the software. But they’re working on a fix and Roon re-establishes a connection so it’s definitely doable. This sounds like something Jussi should be able to provide a fix for.
I hate to say it as I know so many people love HQPlayer, but I really hope Roon don’t get too bogged down with further HQPlayer development. People asked to be able to use it, and they delivered. And they delivered before they’d finished and released their own network end point software. Not many companies would do that.
Obviously there’s no harm in things improving over time with HQP where they have resources, but personally I’d much prefer to start to see their own inovations come to fruition so that Roon becomes the product they really want it to be. Hopefully down the line Roon will provide all the tools people need so that third party programs aren’t necessary.
Well, judging by the talk at launch of Roon, their own DSP and possibly RC are all possibilities but of course will require development time, we could be talking a year+ here. So the HQP integration is very welcome as a ‘stop gap’, it shows that it is possible to have the best SQ with the best front end music manager out there.
Just this NAA disconnection issue, at least when using a Mac as the host for NAA is a bit of a bind. Don’t want to lose HQP if possible, maybe a new thread specific will glean some suggestions from people who have trodden the Pi/Cubox/BBB route.
allen, have you contacted the developer? He may well be aware of it and be working on a fix, or if not I’m sure would be able to work it out. I know what it’s like - my headless server dropping Dirac was an absolute pain and rendered the system useless - I’m not about to get people to VNC into a machine to sort things like this out just to listen to music!
Steve, Signalyst have various NAA builds for the the devices mentioned, but as far as Mac OS is concerned you can only download an executable file which runs in Terminal on the Mac. It runs fine when everything is ‘on’ but has no way to recover other than re-starting if the connection is dropped (AFAIK).
You should quit HQPlayer before powering down the DAC. If the DAC is lost in action, you either need to go to the Settings/Preferences dialog and re-select the DAC when it is available again, or restart HQPlayer.
NAA is like a DAC for HQPlayer, so from this point of view it doesn’t matter whether the DAC is local or remote through NAA. NAA itself doesn’t care if DAC comes and goes as long as HQPlayer is not connected at the same time.
Thanks Jussi for the explanation which mirrors what I have happening. But that is the issue I am raising, having to go to either HQP on the server machine (iMac with Roon Core) or the Mac directly connected to the DAC by USB, running NAA.
Why can’t these connections persist? Why can’t NAA simply look out for the USB connection (set as default) so that when the input is selected on the DAC unit (Devialet in my case) whether from power off, sleep or simply switching inputs, it is back up and running without all this phaffing around with restarting HQP or the NAA, or both?
Roon can do this, but not HQP?
Will one of the other devices running slim software be a better bet than Mac using NAA?
On Windows, the WASAPI backend re-opens the device every time playback is started (due to annoyances Microsoft introduced in Win8). So that would probably work best for your case.
All other backends keep the device open and reserved all the time and expect the driver to maintain a proper device state. When the device goes away while being in use, bunch of strange errors result and the driver naturally loses the device state it had.
Not ever going down the Windows route just for NAA. So it seems that I have to keep my Devialet (DAC) and MacMini (NAA) permanently on, 24/7. Which I have been doing (but want to change) and yet from day to day, the connection will still drop sometimes, not always, but more often than not. So I currently have to share screen into my iMac (Roon Core &HQP) and my MacMini (NAA) on a daily basis and restart or check settings for HQP & NAA. Which is a phaff, and not for lay-people such as family members! Surely a bit of code in the backend could make the default connection persist or at least be searched for? Sorry, not trying to be glib, but I am not a programmer.
What about dedicated NAA’s, such as the like form Sonore, is this the situation with them? I will happily stump up for a Sonicorbiter SE or microRendu, but not if they require re-boots every time my Devialet re-initialises the USB connection.
I had a similar issue. When I started with HQP, the DAC for my two channel system was out. So I used an OPPO-HA2 for Headphones. With a Sonicorbiter connected, when I turned that DAC off at night, it would completely disappear as a device from HQP. In the morning I had to reboot HQP and the Sonicorbiter for the DAC to be recongized.
I have RoonServer + HQP (Windows 10) running 24/7
I don’t know why, but I found that if I named NAA, the issue disappeared. I could turn the DAC off over night and turn it on again in the morning with no issues. I do have 1 caveat, the Sonicorbiter has an SPDIF interface that HQP does recognize, so I don’t know if the naming the device + the SPDIF interface keeps the connection with the NAA alive.
Now I have my main DAC back. It’s connected to the Sonicorbiter. This DAC, even though powered off, is still visible to the NAA and HQP. Again, I’m not sure why, maybe the USB interface remains active when the DAC is off. But with this DAC, I haven’t lost a connection, it’s only been about 3 days, since I got it back , but I haven’t had to restart the Sonicorbiter or HQP once.
BTW, I setup an NAA on an ATOM PC running Linux dedicated for the OPPO, and really haven’t had any issues powering on and off, but did name that NAA in HQP as well.
Here is a picture, SSO is the name of the Sonicorbiter and the DAC connected to it is powered off at the moment. The OPPO is on.
Thanks @Erik_Brockmann, that’s really helpful. At least there is hope somewhere!
I am pretty sure that my Devialet does a ‘handshake’ with what precedes to say, hey, this USB is now alive when switched to it. As you also say, it could be the SPDiF on the SoSE that is keeping things alive on that unit.
I have the NAA named in Roon, but are you saying you named it within HQP settings?
As per the other thread, you can name an NAA using it’s IP address with the Network name tool in HQP under the Tool menu. I haven’t extensively tested it but my recollection is that once an IP address is named HQP will remember the device as it comes and goes.
Thanks @andybob, yes I had pretty much worked that one out, although naming it in HQP settings does not make any difference in my setup. What I did do is give the MacMini running the NAA a fixed IP address on my network, so HQP running on the iMac (Roon Core & HQP) has no problems locating the machine. But since NAA runs in a Terminal window and loses the USB connection ( switch off, switch input or sleep on the Devialet) then HQP defaults back to ‘core audio’, i.e. the internal speakers of the MacMini (which is all that it can then see on the NAA). Thing is, you can’t disable the core audio, probably for obvious reasons like OS X system alerts etc.
Ultimately, this means a restart of the NAA with the Devialet on and USB live, then HQP on the iMac server will see it again, however, once again you have to enter settings to switch the output in HQP.
Thing is I am quite happy to ditch the MacMini and switch to Sonore or Cubox if this keeps the USB connection going, even if the Devialet is ‘off’. I do have a Regen, but it’s on it’s way back from Uptone after some TLC, so I cannot test the persistency of the Regen being permanently powered up whilst the Dev is off just now. I rather suspect the Regen is benign in this situation though, it just passes on the Devialet’s handshake when switching to the USB input.
Agreed @anon94274355, it does seem that the the whole HQP integration with Roon is fine for the ‘twiddlers’ amongst us, myself included, but is not suitable for other users not versed in the whole set-up. Defaulting to everything involved being on 24/7 does not seem a suitable scenario, even if this does not bother your green sensitivities.
The SQ is outstanding, but the phaffing around with settings every day is getting to be untenable. Fine for audiophile listening but everyday use? Well some way to go before it hits prime time, unless someone can confirm other routes (that do not involve Windows)?
Exactly my point @AllenB . Personally I haven’t used HQP in almost a couple weeks and I can’t see myself purchasing further versions if this will always be the case… sometimes we just want to play music and honestly for some deep listening sessions, I’ll always go with my vinyl setup over my digital one.
I don’t have my devices powered on 24/7, and that also includes my Macs. I close all applications and shutdown the computers when not in use. And when I want to use those, I boot things up and start the applications. So no issues.
So there are only issues if you want to power down only part of the system, but not everything.
The iMac is basically now my music server, on most of the time with Roon Core and HQP usually the only apps running. Sometimes iTunes but not very often.
My MacMini has been re-purposed as the NAA for HQP, it is lean, hardly anything else running. This tends to stay permanently on also. Thinking of replacing it with a slim device for the reasons already documented.
My Devialet 200 is the unit that gets turned off or automatically goes into stand-by after a set time (4 hours). In fact, turning off means going into stand-by state also, to turn off completely, you have to hold the power button down fro 4 seconds, similar to a computer.
Yes exactly… but only HQP has this issue.
Roon, Audirvana, JRiver, iTunes does not have this issue.
It is not just turning my dac (Unison Research CD Due) off but say I change the source so I can play a cd and back to USB the connection in HQP is lost.
Please let me know if you will be looking at fixing this issue in the future, if not my use of HQP will be very little or at all in the future, not all customers work with their system the way you do and should not be told to do so a app works correctly.
I don’t see why Roon should spend so much of its time and effort becoming a user friendly front end to a piece of bespoke Audiophile software that only a subset of Roon users will ever use. Aren’t most of these people tweakers anyway who are willing to mess with it. Roon sending its output to HPQ like other endpoints fine but beyond that its really up to HQP to improve its interface and usability rather than expecting that from Roon.
I would much rather Roon spend its time on effort on delivering things such as Roonspeakers, full meta data editing and many other things of much wider use.
)