HQPlayer Embedded Discussion [2023]

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.

1 Like

Are you sure you can connect a dac to the ifi Neo Stream? According to this page usb ports are for input and not for output

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.

You’re right … missed that picture

1 Like

ADI-2 requires DoP for DSD to work.

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?

All working as intended, I had to tick DoP for the RME ADI-2 DAC.

Ubuntu Server 22.04.1, HQPlayer Embedded 4.32.0, ongoing warnings

Discovery request did not have a valid MX header

Please use latest version first, 4.33.3.

How is the network setup? DHCP or fixed IP? Internet reachable?

I’ve not updated in a while, for i9-11900 do I use amd64 or avx2_amd64?

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.

1 Like

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.

Discovery request did not have a valid MX header













































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.

Some device on your network is returning invalid SSDP responses, but I think you can safely ignore this error.

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?

Like to confirm Offload/CUDA is working, which I think it is based off of I see a “R” in the Offload column and the following:

1 Like

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.

1 Like

Yes, seems to be working fine!

Someone at other forum asking this:

hqplayer has scripting or an apii to script externally?
Yes, a REST api to control the player.

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.


Thanks! replied already

1 Like