Specify or limit core usage in HQPlayer

See title, is this possible?

The reason I ask is that I run HQPlayer + Roon on my normal desktop computer (a Ryzen 5950x) and usually do other stuff at the same time. If I could, for example, assign core 6-16 to HQPlayer, core 5 to Roon, core 1-4 to Chrome + whatever else I do it should stabilize things.

It’s possible to do this in windows, using task manager detail view, but HQPlayer crashes if I do that:
image

Any solution to this? As it is now, I get the occasional drop-out even at DSD128 with asmd7ec, despite the CPU usage only showing 7% for HQPlayer.

Or any other fix I can try?

PS: yes I know I should run HQPlayer + Roon on a dedicated computer, but that costs money and if possible I would like to avoid it.

Curious, did you enable the CPPC in BIOS? And also what’s the Windows version you’re running?
https://www.amd.com/zh-hant/support/kb/faq/pa-400

You can use HQPLAYER_RESERVED_CORES environment variable. It takes in binary bitmask of processors that HQPlayer shouldn’t use.

But please note that such shouldn’t be necessary, if you are getting dropouts with stated settings, there’s something going wrong with the OS. It should work fine with stock Windows 11.

I ask just in case, that you haven’t used any “optimization tools”? Those almost systematically screw up the system and HQPlayer performance one way or the other.

Hi Jussi does such environment variable apply to HQPlayer Embedded as well?

No optimization tools, although I have tried changing the priority for Roon and HQPlayer process (didn’t make any difference).

Still on Windows 10, upgrading to Windows 11 now. Let’s see if that makes any difference.

Upgraded to Windows 11, and removed a bunch of stuff (MSI Center, cFosSpeed, NVIDIA Experience, etc) but still have the problem. Now I am testing ext2 PCM upsampling to 192khz, which on my computer takes around 0.5% CPU, and still has the problem. So it’s unlikely it’s CPU related.

The drop-outs are very short, like 0.5 seconds. Could it be NAA related? Network seems unlikely since 192khz PCM should not take a lot of bandwidth.

Yes, it’s the same for both.

That’s a bad idea. HQPlayer has a lot of threads, some dealing with GUI, some dealing with audio, some dealing with other tasks. Each has it’s own carefully designed priority. They don’t all run at the same priority, on purpose. Trying to externally adjust this may result in something like GUI getting more priority than the audio processing, or all threads getting same priority, which is certainly not something you’d want.

If you are streaming to a NAA, try first without a NAA with direct USB connection. If it then works, you know it is either network or NAA related.

Even with 192k and certain NAA hardware, you can still have drop-outs if 802.3x is not becoming enabled on your network. What kind of network infra do you have? Unmanaged switches? Managed switches? WiFi?

One possibility is also that low CPU usage drives Windows into power saving. So make sure you have “High Performance” or “Ultimate Performance” power profile selected in Control Panel → Power.

1 Like

I run a dual network-card setup in my computer, regular copper ethernet for normal usage, and then a fiber NIC PCIe card that connects to an opticalModule and then to a streamer. I then use Connectify to enable the isolated fiber network to talk to the normal network.

I tried to use a windows 10 network bridge, but got blue-screen occasionally. Maybe I should try that now that I run Windows 11.

Complicated system setup Magnus !

Time to simplify my friend - the headaches and blue screens of death will come to an end :grinning:

Connect your optical module to a switch with optical SFP. And connect everything else to the same switch too, including your internet router. Just a single network, no need for additional NICs on a computer.

3 Likes

Found the problem, and it had nothing to do with CPUs, network, or even HQPlayer :slight_smile:
I had my RME DAC source set to auto, and my TV plays to toslink, but it seems like the TV sends some garbage occasionally (even when muted) that makes the DAC switch to toslink, then right back to USB.

After changing input on DAC to USB, it has played perfectly without hiccups.

Cheers for help anyway!

3 Likes

@jussi_laako I tried with the environment variable that specifies available cores to use for HQPlayer, but it seems it uses all cores anyway.

What I would like to do is to divide my CPU in half, let HQPlayer use cores 9-16 and the rest use core 1-8, with the help of for example Process Lasso. My current CPU, Ryzen 5950x, is powerful enough to handle pretty much everything on 8 cores anyway (games, etc), and can easily run 7ec + DSD256 on 8 cores as long as its not disturbed.

So you have set

HQPLAYER_RESERVED_CORES="1111111111111111"

?

Or something else?

I have 16 physical cores, 32 logical ones, I guess it depends on how HQPlayer uses a core. HQPlayer should not use the first 8 physical cores, and with the help of Process Lasso I will set everything else to use only the first 8 physical cores (I would guess I should not tell Process Lasso what HQPlayer should use).

Yes, above should do that.

Yes, that would screw up the work allocation logic in HQPlayer.

Got it working now, had to be set in system variables. But HQPlayer still uses the excluded cores a little, maybe DSP engine?
image
This is from 192khz source to DSD256 + ext3 + ASMD7ec, which still gives some hickups (probably would work ok on dedicated machines though).

Ahh, yes, HyperThreads are allocated for some tasks before the reserved cores is taken into account, this is now fixed for the next release.

1 Like

I did notice one peculiar thing. I used HQPlayer as a benchmark (playing to null, measuring time to play 1 min of a 96khz tune), and it ran faster with 8 physical cores disabled (27 s vs 34 s). This is maybe not that strange (less overhead) but maybe don’t automatically use all cores on a Ryzen 9 5950x (or other CPUs with lots of cores).

It would also be nice to have the core selection in the GUI instead of through environment variables which are a bit non-windows.

It is also because you can then gain higher turbo clocks for the remaining cores. It may be a bit different running to a non-null output though, because the load is then limited by the playback speed instead of processing capacity. Earlier I left two unused cores in such cases, but people were complaining that not all cores are utilized. When you want to push for higher output rates, such as DSD512 or DSD1024, you may need all the available cores. Or if you have more channels, for example playing 5.0 or 5.1 channel material.

Environment variables are totally typical Windows, Linux and macOS. Windows itself uses environment variables for many things, such as PATH, LOCALAPPDATA, etc.

These kind of things that are rarely, if ever, used are perfectly fit to handle through environment variables, instead of dedicating GUI for something where there is lot of potential to just screw up things.

I personally never use the option in question, since it is not useful or necessary for any of my use cases. And I would still count myself as a “power user”.

1 Like

Ryzen doesn’t have any turbo-clocks, but PBO (Precision Boost Overdrive) is sort of similar (but better) for Ryzen CPUs. Btw, safe overclocking on Ryzen CPUs is to set PBO to enabled and PBO limits to motherboard in bios (not sure why it’s not enabled by default).

I will try an experiment later today, set HQPlayers allowed cores to the 6 cores on the second chip (2 chips with 8 cores each in Ryzen 5959x) than is not “preferred”, which should mean that the cores used by HQPlayer is left alone from Windows as much as possible.