Solved, had to enable DoP for the ADI-2 DAC FS w/ ESS chipset.
New to HQPlayer and ROON. I have HQPlayer Embedded and setup in ROON playing to an iFi Neo Stream (internal DAC) just fine. However, I have a RME ADI-2 DAC attached to the iFi NEO Stream via USB and selected in Playback Options on the iFi NS, selected in HQP as a device I receive no sound from the RME DAC. I have made sure nothing has control of the RME DAC, from ROON looks like all is good, but no sound from the RME DAC. Also, I attached the RME ADI-2 DAC to an instance of HQP NAA OS and enabled NAA, selected from the GUI of HQPlayer, Network Audio Backend and no audio from ROON.
If I play from HQP Embedded I am able to receive audio through the HQP NAA and the RME DAC.
Yes, you can, there are 2 USB ports and works fine w/ other audio workflows. I also have the RME DAC attached to HQP NAA OS and same issue from ROON. I can however play/source from HQP Embedded to the RME DAC/NAA just fine w/ the exception of DSD.
But I’m a bit lost now on what works and what doesn’t. So does playback from standalone HQPlayer work? But not from Roon through HQPlayer? Does the playback time still proceed on both?
AVX2 package is the right one when your CPU supports AVX2 (any Intel Core since 4th Gen and AMD since Ryzen). You can try with either one, but likely the avx2 one performs better.
Installed the AVX2 4.33.3, same MX error, below. HQPlayer server and the NAA endpoint have fixed IPs assigned as static DHCP leases by the router, an Ubiquiti EdgeRouter PoE doing firewall and NAT downstream from a Motorola cable modem.
Hum… I have a dynamic DNS service on my router that I set up ages ago for reasons I can’t even recall, could that be the culprit? Nope, removed the service, still getting the errors.
Thanks, that’s useful. What’s weird is that I’ve not added or removed anything from the network in the last 6 months, so it must be an errant software/firmware update. Is there a way of determining the source?
That message is from the UPnP software stack. So it is likely some UPnP device, or something else using SSDP on the network. But I wouldn’t really worry about it too much. It shouldn’t affect functionality unless you are using specifically UPnP and encountering problems. Most likely it is some device with UPnP Renderer capability (like HQPlayer is too). For example your smart TV or similar.
It is not at all unusual that UPnP devices have some bugs resulting in incorrect items in their messages.
It has XML-over-TCP control API. You can find client side reference implementation along with the hqp-control2 source code at the end of the page here:
For simple things, one can just call hqp-control2 utility which is included in all HQPlayer Desktop builds.