How many DACs generally have the habit of disappearing from the USB bus when changing inputs? I don’t see a big problem closing also HQPlayer when turning off DAC. As name says, HQPlayer Desktop is not designed for headless use. I’m running headless HQPlayer Embedded on Intel NUC and it doesn’t have any display or graphical output at all. System is started by pressing power button on the computer, and it takes about five seconds to boot up to HQPlayer running. And pressing power button again shuts it down which takes about two seconds. So it is easily turned on/off at the same time as the DAC too. However, it is not compatible with Roon at the moment but can be controlled with BubbleUPnP running on Android device and source media from something like MinimServer. Making HQPlayer Embedded also Roon compatible is one possibility for future development.
By the way, with Windows and Linux versions of HQPlayer you can play CDs straight using HQPlayer. On OS X I didn’t implement the functionality because Apple has not been shipping their computers with optical drives for a while.
Okay, I guess you will not fix this for people who run a headless MacMini system. With the 30 minute trial you offer we were really never able to see this happen.
I would like to request a refund for HQP then because I should not have to change the way my system is setup and the way I work to use your software.
I would also really like to see this made possible. Before reading this thread I was actually thinking I was doing something wrong with HQP. I always put my Devialet 250 In standby and noticed this behaviour of HQP needing a restart. It makes HQP, which I like very much, unfortunately a lot less usable. Now I understand this is by design
So that appears to be a ‘No’ then. I find this somewhat disappointing when the server (not necessarily headless, mine is an iMac) running HQP (and Roon) could be in another part of the house and not as convenient as your own power on/off. The whole point of the NAA is to have it on a network endpoint connected to whichever machine by, in this case USB, yet it cannot handle consistently the USB input on that DAC being switched or turned off. I just could not let my family loose on the current state of affairs, as it stands it remains a lottery as to whether they will hear music or not.
If you want to make absolutely sure NAA doesn’t get upset by DAC disappearing, then the good’ol unidirectional S/PDIF works fine, sine NAA wouldn’t even know when DAC is on or off. On Devialet it doesn’t seem to make much difference in terms of jitter whether to use USB or S/PDIF. And since it goes up to 192/24, you can anyway stick to coaxial S/PDIF. Possibly something inexpensive as RasPi2 + Hifiberry Digi+ could work fine. Or alternatively some good quality USB -> S/PDIF adapter with something else than RasPi as a NAA.
@jussi_laako I currently use an Uptone Regen into the USB input on my Devialet 200, and very good it is too. I am seriously considering upgrading that to the microRendu when it is available. The latter will replace either or both the MacMini and Pi 2 that I am currently using for HQP NAA. The USB cable is a Chord Signature TA, so you will see that there is already a decent amount of investment here. I am not about to change hardware and type of connection just to get a stable connection from NAA.
The real question is whether, you as the man behind HQP and NAA is going to resolve the USB connection not working on all machines, and I think the answer is No. Which leaves HQP as purely a audiophile hobbyist method of listening and not for general use.
Now if you were to loop back your output to Roon and allow it to properly control the music player side of things (including input switching), then we have a workable solution for everyone, through one slick interface. I have read your concerns about losing control on SQ, but isn’t this a decision for us users to make. I doubt that the Roon guys would do anything other than to diminish your output via Roon. For users that want to have your view of controlling the quality of the output, well the current status quo seems to keep those users happy.
I think it works OK within the constraints of USB itself. If you unplug USB device at inconvenient moment, like HDD while writing a file or audio device while playing you will end up with inconvenient results.
I don’t think it would change anything…
You can first try how RAAT behaves if you unplug and replug your DAC to a Linux based RAAT while Roon is playing and see how it behaves.
Sorry @jussi_laako, I am getting slightly annoyed now, both of your answers are a kop-out in my opinion, you are dancing around it and using USB as a shield.
Firstly, how can something (NAA) that is supposed to run on a supposed discrete network endpoint such as a slim device, with what should be little user intervention once the mode is chosen, not be able to cope with inputs changing down the line on the DAC/player.
Secondly, I think you are being a little disingenuous to Roon, one of their devs has written that Roon sends commands that ensures USB connections used for output are ‘re-seen’ even if it has been switched on the DAC / player device. I am sure that would also be the case with their RAAT, and the machines that employ RAAT. Even in the meantime, Roon have provided a break in the audio chain via their interface for instances when the HQP main program has locked up.
It really just needs you to loop back the HQP output back into Roon, and I would bet you would have even more of a take-up of licenses for your program. It also gives users who want or will have RAAT, in one form or another, a chance to use HQP within Roon. At the moment RAAT and HQP NAA are mutually exclusive.
There is a whole topic here about integrating HQP further into Roon. It appears to be eminently do-able, with firm assurances that HQP SQ will not be intentionally harmed. RAAT will be the de-facto protocol once we have 1.2, whether local or network distributed. Looping HQP output back to Roon will allow it to be delivered to all suitable appliances by one of the Roon methods, which opens up all the RAAT capable devices, as well as those that will use it via RoonBridge. One point of control (so long as HQP is running alongside Roon). You would not need NAA on any devices to keep using Roon, as is the current situation, you will just need RAAT or RoonBridge. As it stands now, you will have to choose, RoonBridge / RAAT or HQP NAA, one has to have control of the appliance at the ned of the chain. Without a doubt in my mind, this should be Roon, as far as I am concerned long-term that is what it will always be for my system, why I am a Roon lifer.
That is my understanding, and it just seems like a win-win for HQP and Roon. I can understand @jussi_laako being precious about his software, but for those that have any doubt about SQ through Roon, they can always revert to NAA or HQP Desktop. But for Roon users, it would allow a infinitely more elegant solution (even if only temporary until full built in DSP enhancers are developed by Roon, which may be a derivative of HQP, down to a deal being struck I guess) to enjoy the undoubtable benefits of HQP as well, and why I bought 2 licenses. Furthermore, my main interest with HQP is it’s ability to convert PCM to DSD, but the range of filters are also better than other similar software I have tried in the past (Audirvana, Pure Music, BitPerfect, Amara).
It would be a crying shame if the current link between Roon and HQP is all we will ever get, because long term in my system, HQP would have to be dropped, my family could not cope with the nerdy fiddling required to keep USB connections alive.
NAA is intended to be built straight into a DAC, being able to use it with USB DAC is more function of the OS it runs on rather than function of the networkaudiod itself.
Generally, I’m not big fan of USB in first place.
Let’s see how it’ll work in practice…
I’m not sure if it would introduce more problems than it would solve… I have a feeling that such combination would more resemble a Frankenstein Monster. At minimum it would require complete rewrite of both HQPlayer and Roon’s audio system to properly integrate the two. That’s work worth many man years effort.
Jussi: I fully understand the preference for optical Ethernet and I wish that more DAC manufacturers provided for that form of input to their DAC. But today almost none do. So, what do you see as the best path between an optical Ethernet output and the typical choices of DAC inputs (USB, SPDIF, RCA, AES) ?
Yeah, Merging is one of the rare ones. There could be more though…
What ever ends up as complete system architecture, there can be some usability limitations due to various technical details of the components involved.
It depends on the DAC, there is no single “right answer”. It also depends on the use case. If one wants to have complete safety from DAC disconnects, then some unidirectional interconnect towards DAC may be better choice than USB. With S/PDIF and AES the sender doesn’t know if the receiver is present or not, it just blindly spits out data, so you can pull out the cable at any moment and put it back later at any time and there’s no problem. With USB or ethernet that is not the case… (although ethernet can be made to behave in same unidirectional way, but then it is of course not asynchronous transfer anymore)
Care to elaborate what problems would be introduced? Frankenstein Monster seems a bit strong, so you should elaborate. A complete re-write is not what i have read from the Roon guys if you hand over your output from HQP back to Roon.
Well, Roon guys don’t know how HQPlayer works inside. And I don’t know how Roon works inside. But unless you want to introduce huge lag/delay the HQPlayer output needs to be tightly coupled to the audio hardware. In order to operate, HQPlayer also needs a lot of information about the output hardware and then ensure that the output is passed bit-perfect to the hardware. HQPlayer also needs access to change the output hardware settings and such.
It is not as simple as putting output somewhere. A lot happens before you have any output at all in first place. And then a lot also happens while playback is proceeding and for example when you need to switch the output sampling rate or switch between PCM and DSD modes.
The only output information you would need is RAAT, Roon would control all aspects of the hardware and settings interface.
All I am reading here is that you will not release control of any part of your process. Which I guess is your prerogative. Which in the long term means that HQP is of little use to a dedicated Roon user especially when RAAT and RoonBridge become more mainstream, as it surely will. Your slim association with Roon was brief, but it can go nowhere whilst you do not give Roon the means to make your software of more widespread use. HQP will remain niche for CA nerds.
