@jussi_laako: When doing DSD256->705Khz PCM, my audio stutters even on a powerful i9 laptop with certain filters (e.g. poly-sinc-gauss family). I have a 3080 GPU on this laptop, but even with GPU usage enabled (and Offload:resampler=“enabled” shows when starting playback), in the Task Manager the GPU usage shows 0% throughout. It seems like the GPU is not actually being used. What could be the problem? Latest nVidia drivers are installed. Multicore is also enabled.
Windows task manager shows completely bogus load figures for CUDA offload. Open command prompt and run “nvidia-smi -l 1” there to see the actual load. That argument means “loop every 1 second” to refresh the figures, you can also use less frequent interval such as 10 seconds. It should list HQPlayer4Desktop process as “C” meaning compute. Most other tasks are “C+G” meaning they use 3D graphics, such as OpenGL or DirectX.
If you are converting DSD256 to PCM, please check your “DSD Source Settings” in HQPlayer. These can have pretty big impact on the load.
Thanks. It does in fact show the HQP process as “C”. However overall load (shown at the top) is only 1-2% and the audio still stutters. CPU and memory load are also low. My DSD Source Settings are medium/poly-gauss-long/FIR2/XFi. What could be the problem?
Just to check which setting is causing the problem, you could first try “standard” as noise filter. If that doesn’t make a difference, you could check with “traditional” as conversion algorithm.
When playback stutters, you cannot trust the load figures, because the load becomes so sporadic.
It seems to be happening when the HQPlayer Desktop window is not the in-focus window, i.e. when I’m doing something else. Switching focus to HQPd seems to fix it. I used Task Manager to change the process priority of HQPd to high and realtime, but that didn’t change anything.
Is this stock Windows, not “tuned” or “optimized” with any tools?
You can try setting Windows power profile to High Performance.
I haven’t customized Windows in any way, but it is an Alienware (X17) laptop which I believe has various manufacturer customizations. It is plugged in. I tried changing the “thermals” setting in the Alienware Control Panel to “performance” and even “max”, but that didn’t help, plus the fan noise is way too much with those settings.
Is it any better with CUDA offload disabled? This would help finding the potential issue.
The problem persists with CUDA offload disabled.
Also, even with CUDA disabled, switching windows (focus) to the HQPd desktop application immediately solves the problem, so it seems like GPU processing is not “needed” in this case (DSD256->705Khz).
There’s a Windows setting where you can choose, if Windows gives priority to foreground processes or more priority to background processes.
Strange thing is that HQPlayer already asks for high priority and I have not seen similar behaviour myself. So it could be some modification Alienware has made to their Windows installation. Which I understand could make sense for the assumed gaming usage focus.
Yes, this is quite likely an Alienware issue. Thanks for all your support!
Try setting that background tasks priority instead of default foreground tasks priority. It could help…
Tried this. It actually seemed to make the problem worse: audio started to stutter even when HQPd was the foreground application.
That is strange.
Since it is an Intel CPU, please try with both “Multicore DSP” set to grayed and set to checked. This will likely change the CPU load patterns significantly on your machine. This could be the answer.
Can you also post screenshot of Windows Task Manager resource usage tab where CPU load graphs are set to display per-core loads?
It had Multicore DSP set to checked. Changing to greyed doesn’t change anything. Unchecking completely makes it much worse.
The screenshot is below. This is during playback. All 8 cores (16 threads) are apparently being used, but usage is quite low. The HQP process is listed in the top left.
Looks normal. It is expected that unchecking Multicore DSP will make it much worse. But there should be quite a bit of difference between grayed and checked.
Loads look pretty normal and none of the cores are close to 100%, so it should work fine also in the background.
Which DAC is this? If the driver has control panel (in SysTray), please check the ASIO buffer size and adjust it to maximum size. If there is no control panel, try setting the “Buffer time” in HQPlayer to 100 ms. When set to “Default” it will use the value proposed by the driver which is the normal setting for ASIO backend. Not all drivers allow buffer adjustments by the application.
The HQP Desktop instance is streaming via NAA in a Raspberry Pi4, to an SRC-DX connected to a Chord DAC. I played around with buffer sizes but it didn’t change anything. Not sure if the OS on the Pi4 has any effect on this. I’m using AudioLinux - The audiophile realtime plug & play operative system (audio-linux.com).
OK, I see, I was first assuming local DAC connection.
I would say it is more related to network interface power saving modes or similar. Is this wired or wireless network? Any switches or similar involved?
You can always try my reference NAA OS image on the RPi4 for comparison. But I think this foreground/background behavior is not related to NAA, but more to the HQPlayer machine.
It’s a direct ethernet connection between the laptop and the RPi4, except for a Pink Faun LAN Isolator. I’m using a local DHCP server on the laptop, created with Tftpd64.
I tried removing the LAN Isolator from the connection, but that didn’t change anything.
Yes, I agree that this problem is probably originating from the laptop, especially since it’s doesn’t occur when upsampling PCM->PCM, or even DSD128->PCM. It only happens with DSD256->PCM, and gets much worse with DSD512->PCM.
It also seems to increase with general system activity, e.g. opening new browser windows, opening/closing applications, etc. I thought maybe it could be a disk I/O issue, but it happens both when the DSD256 files are on an internal & external SSD, and both are high-performance SSDs.
It really sounds like hitting some power cap in the case when it begins to stutter. And since foreground/background changes things, Windows is not honoring the scheduling requests from HQPlayer.
Have you ever considered trying Linux in a dual-boot setup?