I’ve just got a Mac mini M1 and an Up Gateway endpoint running the NAA binary to drive my Holo Spring 2. The Mac mini is up, the Up Gateway shows up on the network and can be pinged. but I can’t seem to HQPlayer Desktop to the endpoint. I choose NetworkAudioAdapter on Output Device Settings, but I’m not allowed to select anything for Device. The Mac mini and the Up Gateway are on the same UniFi switch. Desktop is in demo mode, as I wanted to check that everything works before buying the license. Am I missing something?
There’s a globe network icon thingy on Desktop. Did you enable that? Sorry I’m not at home so can’t share a screenshot of what it looks like.
Wait did NAA is fully booted first, with your DAC already on.
Then boot HQP Desktop last.
Thanks, but that seems to be for the input side, what I’m not getting is the output side. In any case, toggling that does not allow me to configure the output NAA endpoint.
It’s for output but if it isn’t doing anything I can’t figure what could be the issue.
Can you share a screenshot of what you see?
Try ipv6 option?
Disable macOS firewall also
Quit HQP and re-open
Also how many NAAs are you running?
2 more more running NAA OS ?
They will both have same name and nothing will work.
So need to change one of their names.
To test, power off one of them and other should show up
This seems like discovery problem, where either multicast message looking for NAAs is not reaching the NAA, or the response from NAA is not getting back to HQPlayer.
Please check that you don’t have multiple network interfaces active on your Mac. For example if you are connecting through wired ethernet, try turning off WiFi.
You may also need to enable IGMP Snooping on your Unifi switch.
Just one NAA OS device at this location. Mac firewall off. Turned off WiFi on the Mac mini, just Ethernet on. Turned on IGMP snooping on my Unifi network, although I like it off because of past issues between it and Roon device discovery. Rebooted Mac just in case. Still the same problem.
I wonder if NAA OS is getting DHCP address properly. You could login as “root” and run “systemctl status networkaudiod”. It shows also snippet of the log so you may be able to see if there have been discovery messages. For more elaborate output, see “journalctl -u networkaudiod”.
Well, now we are getting somewhere, networkaudiod is failing to start with “Dependency failed for Network Audio Adapter daemon”
Looking at the full logs, it looks like systemd-networkd-wait-online.service is failing. Before that, an IPv4 network address had been successfully assigned via DHCPv4, but then there are some questionable lines:
Bad value for ‘hidepid’
Could not set hostname: Access denied
This is on an UP Squared Pro Edge Atom 0464 E3950 because the Up Gateway I use on my other system was unavailable. Could that be an issue?
I could be wrong but …
It has two Ethernet ports (isn’t it?) and NAA OS cannot choose the port, have you disabled one of the in bios?
Alternatively you should use HQPe OS and disable HQPlayer Embedded letting NAA, that is integrated in the distribution, run alone.
In this way you’ll be able to change the name too
Thanks, great point on the two Ethernet ports, I’ll try to disable one of them in the BIOS. A bit surprising as I thought carrier sensing would be built into the Linux networking stack. Oh well.
Update: Spoke too soon, the BIOS don’t seem to offer any way to configure the Ethernet ports. I guess I’ll try the HQPe OS option.
Default rule set for NAA OS is to wait for all network interfaces to become configured before networkaudiod is started. This is because network setup is asynchronous process with unknown amount of delay. Assumption is that all network interfaces enabled on NAA device have a purpose.
HQPlayer OS works around this by bridging all ethernet interfaces and then assigning IP on the bridge interface through DHCP. Thus it is enough if one of the ports are operational. Down side is some amount of extra overhead due to the bridge. However, on typical HQPlayer Embedded server use cases, this is something totally unnoticeable compared to the loads posed by HQPlayer itself.
But the decision for NAA OS to use interfaces directly, without a bridge is intentional to absolutely minimize all OS loads. However, HQPlayer OS is dual-use for NAA purposes as well, precisely for this reason. I’m running HQPlayer OS on an older UP Squared (one with Pentium series CPU).
If I would have known it was UP Squared instead of UP Gateway, I would have known immediately why NAA OS is not working…
Thanks for all the advice, my mistake to have confused Up Gateway (which I have at my city place) with Up Squared, which I have here. I’ve got HQPlayer OS up on the Up Squared, and it shows up now in Mac HQPlayer as an NAA endpoint. I’ll test now with actual music. Any suggestions on what/how to turn off given that I just need NAA? Thanks again!
You don’t have to, but you can disable HQPlayer Embedded on the image to make it pure NAA. Just do this:
systemctl stop hqplayerd ; systemctl disable hqplayerd
Then you have a plain NAA system.
Thanks, I tried that but then I seemed to lose NAA after rebooting. I’m using 4.31.0-x64gen, is that the right image?
Should work but there’s newer you could use
the sse42 version unless your UP Squared CPU support avx2
That is something unrelated to hqplayerd running. While if you have hqplayerd running and configured to use some device, then that device is unavailable through networkaudiod because hqplayerd reserves it.