In the readme.txt dated 12.12.2025 i could not find “Capture Rate” and any other possible atributes sync_element may have…
Because the possible values depend on the hardware/driver and not on HQPlayer…
Okey, thanks for explanation. Could i ask what would be those values for UAC2.0 input device ? And for Alpx ? should receive that Digigram Dante board soon…
The USB Audio Class input is preconfigured and ready to use.
As I don’t have this hardware, this is something you need to figure out yourself. But it is extremely unlikely that the hardware would support the feature so you can just ignore these things with such hardware.
Nope, those expansion boards take in sample rate as a word clock, not a 10 mhz reference 
Will have to figure out another boundary device, or since the word clock will be sourced from a PLL board, which do synthesize clock from an GNSS-DO reference, could as well output 48/96k as word clock on 1 output and 45/49mhz on other 8 outputs, since its a 9 output board. 
Hello,
iam new with hqplayer and want to do generally the following:
First Mini PC (Roon Core, Qobuz, activated hqplayer) ----> Second Mini PC (hq embedded on OS Dietpi, only PCM Streaming, Backend= UPNP) —> Linn Akurate ADSM
Does this work generally and if not what to do to get the NAA protocol to UPNP/Openhome which the Linn prefers ?
Quick look on the internet - Linn Akurate ADSM does not have NAA capability. Is this correct? If so, you need to feed Linn from physical NAA via USB for example (or directly from PC with HQPlayer Embedded).
You are right. Linn DSMs do not offer NAA on their Ethernet input. To use HQPlayer, you need some computer that outputs PCM to one of the Linn digital audio inputs (USB, S/PDIF). If I wanted to use HQPlayer with my Linn systems, I’d do it with small (mini PC or RPi) NAA endpoints driven by a beefy HQPlayer server.
One more thing: Linn is in practice PCM-only. Some setups can take DSD, but with major restrictions (no Exact Link for digital connection to Linn active speakers, no Space Optimization).
Hello Igor and Pereira,
thank you for the advise. Means my Linn with UPNP /OpenHome Protocol can not play with hq because it´s not reasonable or possible to convert NAA to OpenHome over gear or software. Maybe in the future i will try it with a Holo Red or gear like that.
Holo Audio RED was a game changer to me – even more than the May DAC.
SQ improved drastically in my system.
I hope you can get one before long. 
I have a guestion regarding combo backend. At the start HQPlayer is using a fraction of a second to sync the output of all combo devices(channels). This time, then adds to the delay between the source and the sound from speakers, about half of a second. Is there any way to get rid of this lag ? I am now working on synthesising word clock from the DACs TCXO to sync the “amaneros within the DAC” with the Dante network. Will this solve the problem ? I wish HQPlayer would start feeding the engine with source AFTER the sync between devices is done…
With stereo setup there are no problems at all, HQPlayer is as realtime as it can be. Dont think there is a network issue, i have upgraded NIC on the HQPlayer box with E810 card, the switch used for this setup is now Aruba CX 6100, with average ping from HQPlayer to NAA under 0.1 ms, flow control is actually working as inteded now.
64 bytes from 192.168.40.66: icmp_seq=1 ttl=64 time=0.092 ms
64 bytes from 192.168.40.66: icmp_seq=2 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=3 ttl=64 time=0.098 ms
64 bytes from 192.168.40.66: icmp_seq=4 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=5 ttl=64 time=0.085 ms
64 bytes from 192.168.40.66: icmp_seq=6 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=7 ttl=64 time=0.090 ms
64 bytes from 192.168.40.66: icmp_seq=8 ttl=64 time=0.091 ms
64 bytes from 192.168.40.66: icmp_seq=9 ttl=64 time=0.082 ms
64 bytes from 192.168.40.66: icmp_seq=10 ttl=64 time=0.087 ms
64 bytes from 192.168.40.66: icmp_seq=11 ttl=64 time=0.090 ms
64 bytes from 192.168.40.66: icmp_seq=12 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=13 ttl=64 time=0.090 ms
64 bytes from 192.168.40.66: icmp_seq=14 ttl=64 time=0.087 ms
64 bytes from 192.168.40.66: icmp_seq=15 ttl=64 time=0.088 ms
64 bytes from 192.168.40.66: icmp_seq=16 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=17 ttl=64 time=0.087 ms
64 bytes from 192.168.40.66: icmp_seq=18 ttl=64 time=0.086 ms
64 bytes from 192.168.40.66: icmp_seq=19 ttl=64 time=0.084 ms
64 bytes from 192.168.40.66: icmp_seq=20 ttl=64 time=0.083 ms
64 bytes from 192.168.40.66: icmp_seq=21 ttl=64 time=0.082 ms
64 bytes from 192.168.40.66: icmp_seq=22 ttl=64 time=0.085 ms
No, the sync delay doesn’t add to the audio delay at all. All audio delay comes from the DSP algorithms and size of the FIFOs and hardware buffers.
This is wierd, on the same system with same settings two channels are working fine, no audible delay, using combo backend with just 4 channels, i get a half o a second delay. I just knock a mic which is attached to the mixer that feeds HQPlayer directly via Dante.
Also wanted to ask if a setup where the DAC and the source are synced with word clock, allows for more then 1 HQPlayer ? i mean to use 1 HQPlayer server for 8 channels and another HQPlayer server for another 8 channels, both HQPlayer should operate transparently if they feed same DAC ?
Do you have the same buffer settings for both cases?
Usually you cannot feed same DAC from two places at the same time. Exception are devices like RAVENNA where you can route channels pretty freely.
yes, i always use period_time=”1” on all network addresses, works fine, -1 doesnt work tho) maybe combo backend has its own buffer settings.
Ofcause both HQPlayer servers will have their own Dante/AES67 card for input, and the Dante enabled Mixer will split channels between them and route them properly. This AoIP is very flexible, reliable and easy to use.
How about the FIFO size?
How about the output, since you specifically asked about sending output from two HQPlayer instances to the same DAC?
As i mentioned before my custom DAC is actualy a box with 8 DSC2 DACs inside that receive clock from a single oscilator. So there would be no problem as HQPlayer sees 8 distinct NAA endpoints. Thats why i asked about combo …
Like i said in the beggining of this project its a long run, but it is in the making now.
Custom Clock Board with 8 outputs 49 mhz and 1 word clock for Dante network.
1 Like
Im sorry i only know two variables for tuning the buffer. short_buffer which is “2” and period_time wich is “1”
Yes, these both should be se on the combo element. It then gets traversed to the sub-engines.
1 Like
Curious about the size of your ALSA input buffer (shown on hqplayerd’s log)? In hqplayerd.xml, the ALSA (i.e. Digigram ALP-Dante-LE) input number of periods and period time also need to be tuned manually and be tested. If you didn’t do it, the auto mode would give you crazy long input buffer…
1 Like