Or broadcast traffic? You could just block such traffic on the boundary?
Unfortunately Roon also does plenty of network scans which is less easy to deal with…
That card has two ports? So instead of NAT you could do the (unrecommended) approach and make the HQPlayer server multi-homed?
Alternatively you can do the same even with single network interface if you utilize VLANs.
Then you don’t need to have NAT or such but you still have two separate networks.
Yes, and those scans are not one of those who improves the soud (
Yes, that is also the variant I was looking at! But I thougt NAT will be more easy way and also will remove ANY agression from Roon scans or broadcast traffic to HQP – that was the goal I was looking for…
But I will look onto another ways if you really think the NAT is a way of trouble…
Also I like VLANs idea!..
Thank you! 
By default the HQPlayer Embeded OS is enabling the “bridge mode” for this card, and as I understand the word “bridge” in networking – it will not block broadcast traffic…
Yes, if you use HQPlayer OS, then you need to tear down the bridge and configure each port individually. This cannot be plug-ang-play, thus the bridge setup.
Bridge is essentially a software based switch.
Hi folks. I am planning to update my dedicated HQPlayer5 PC, which is running all the time (24/7, Ubuntu 22.04.3 LTS with 6.5.0-14-lowlatency kernel), and would like to hear from the group some successful setups or suggestions. Here is my wish list below:
AMD 7900X with 64GB of RAM is in my current build plan. Do I need to go to AMD 7950X for more cores or i14900K for higher boosted clock speed?
Thanks
Hao
For the (5) I would go with 14900K. Because that’s where you need maximum single core speed. Otherwise, 7900X should be good, and 7950X helps with more filters for (4).
So in the end it depends on the emphasis you’d like to put on filters vs output rate. OTOH, filter situation can be improved by adding GPU later, while lack of enough CPU clock speed for modulators cannot be made up for with a GPU.
Thanks, Jussi.
It sounds like i13900KS/i14900K is the ticket to DSD1024.
Hao
Are those new ultralight EC modulators in 5.4.0 not in the debian package, can’t seem to find them after upgrading the package on my Audio-Linux VM.
Yes they are, I just confirmed.
In 5.4.0 Release News,
•Support for buffer level information.
•New low delay mode.
What are these?
You’ll notice the buffer level thing in next release of HQPlayer Client.
Low delay mode keeps minimum amount of data in buffers instead of keeping buffers as full as possible. Mostly useful if you want to use HQPlayer to process audio for video playback for example. So now you have “Normal”, “Short” and “Minimal” buffer choices.
Note that neither one applies to NAAs. To have these over NAA will require a new version of the NAA software.
Thank you!
Fantastic ! I’m sick of using other convolvers for video.
Updated to Version 5.4.0
All good, now 
I’ve learned not to move the Rate on the control app! leave it on Auto, increase rate only on main Configuration, otherwise the rate will be fixed & won’t automatically change making some music unplayable.
@Eminent_One I think you posted a question about this on other forum. On my experience changing the Rate on the app is a bad idea, will override the Auto making some music rates unplayable ( like 48 rates )
You will still get drastically lower delay by using parametric EQ, created for examply by REW.
I can’t see this low delay mode anywhere in settings
Only visible in next Client release you said?
On Desktop, the “short buffer” is now tri-state. Since HTML5 doesn’t support tri-state checkboxes, on Embedded this is now drop-list. This setting doesn’t have effect on NAA yet, since it needs changes to the NAA implementation and amending the protocol.
I just checked manual back can’t find.
No tick = normal?
Tick = minimal / low delay mode ?
Gray = short ?
Yes, you also get help popup if you hover mouse over the control.
Hello Jussi I was wondering if there is a plan for a Raspberry Pi 5 HQPlayerOS image.
