What is it being compared against? So your source is DSD128? But what is the output format? And how does DSD64 and DSD256 sources compare to this?
With correct settings it is OK in PCM mode too at those rates. There are certainly differences compared to DSD256 or DSD512 (depending on modulator) though. Just remember to use the -6 dB PCM gain compensation setting in HQPlayer when comparing, then you have levels matched.
No comparison Jussi. Just a playback in āSDM output modeā @256.
Source files: DSD64 (SACD) or DSD128(Vinyl rips)
DSD Sources settings + modulator:
for the SACD files this old CPU (i7-8665U) does great job with FIR2 + XFi + 7ECv3 / 7EC - Light (quite impressive)
for DSD128 sources Iāve dropped all I could to stay on SDM@256 but stil hickups, so i wonder if this is HW limitation.
So I tried: IIR + wide + 5EC-ulā¦ it still drops every 40 sec or so. I dont think modulator is limiting here.
In this case, DSD128 source is somewhat heavier to process than DSD64 source. Maybe thatās the border where it flips over.
So this seems to just go over capabilities of the hardware. This has been reached with some specific āmulticoreā and ānblocksā setting? If itās really close, and if you have not already done so, it is worth playing with the nblocks. For example values 1 - 4 and see if it is just enough to flip it over and make it work.
Jussi, thank you for a hint! I did mingle with multicore, it is at ā1ā and with this setting it really digested almost all. I have not thought about ānblocksā, for some reason I wrongly assumed that nblocks makes a difference only on systems with CUDA. Iām gonna try! thanks once again.
And the verdict isā¦ itās really a HW performance boarderline. nblocks=ā1ā bring the difference and 5EC-ul becomes very close to stability, but still breaks every minute or so. Non EC modulators, like ASDM7 runs ok. Voila! Donāt really want to mingle with this fanless NUC BIOS settings. In theory it can be āoverclockedā, but most likely it will lead to quick overheat.
@jussi_laako From the description of my Aavik dac:
āāThe digital inputs are routed to an ***ASRC, where they are re-sampled and re-clocked to 200 kHz/24 bit PCM, feeding current output DAC chips.āā
The DAC chipset is a Burr Brown PCM 1792 and offers 4 options: āUpsampled/Non-Upsampled & Fast/Slowāā
If I want to use HQPlayer:
Is it possible to completely bypass the Dac Upsampling? I donāt think HQPlayer can upsample up to 200khzā¦
As I donāt have an option to deselect āfast or slowā ā¦ which one should I use if combining with HQPlayer? (es. non-upsampling/fast)
Thanks
Likely not, since it has ASRC between input and the DAC.
HQPlayer can do any rate, but you are not likely going to find audio interface that would support 200 kHz. So your best bet would be to use 192k output.
āfastā is better option in this case.
Is there an option on backed to enable multicore=1?
Sometimes I forget to do that at major updates and then suddenly I found performance degradation, but actually is improved because of missed doing the update 
.
On HQPlayer OS you mean? Do you use the backup/restore functionality to move over?
Yes, Havenāt used it. When I update new version of hqp I just do this:
hq512@hq512-desktop:~$ sudo dpkg -i /home/hq512/Downloads/hqplayerd_5.0.3-3avx2_amd64.deb
(Reading database ā¦ 200282 files and directories currently installed.) Preparing to unpack ā¦/hqplayerd_5.0.3-3avx2_amd64.deb ā¦ Unpacking hqplayerd (5.0.3-3avx2) over (5.0.2-2avx2) ā¦
Setting up hqplayerd (5.0.3-3avx2) ā¦
Warning: The home dir /var/lib/hqplayer/home you specified already exists. The system user `hqplayerā already exists. Exiting. usermod: no changes Processing triggers for libc-bin (2.35-0ubuntu3.1) ā¦ hq512@hq512-desktop:~$
Restart HQplayer to run the updated version
sudo systemctl restart hqplayerd
Update configuration to multicore=ā1ā
Ahh, so Ubuntu/Debian and not HQPlayer OS. But there you donāt need to do such as your configuration is not touched when you update the package.
I have Embedded on a fan-cooled i9-11900 Ubuntu Server machine. I currently use the following settings: SDM 1x=poly-sinc-gauss-xla, Nx=poly-sinc-gauss-hires-lp, ASDM7EC-super, auto bit rate, 12288000 rate limit. Configuration file has multicore=āautoā. Would multicore=ā1ā allow me to access more demanding options, such as higher rate limits? What I see with btop is 8 of the cores being quite busy, the other 8 not (44.1kHz source).
i9-11900 has 8 physical cores (that can do real work). And another 8 virtual cores (threads) that is just duplication of processor register set, but not execution units. So these 8 extra virtual siblings just reduce OS context switching overhead to half when there are more than 8 running processes.
HQPlayer understands this, and distributes the work accordingly, making optimal use of this hardware.
You can try with multicore=ā1ā if it helps in your case. It may make things better, or worseā¦
Thanks for explanation! Cores 0-7 are kept pretty busy with āautoā already.
It happened only on mayor updates only, like it tells me to keep or override configuration file, I should check keep the next time I guess.
In my case i913000 Unbuntu using multicore=ā1ā it does improve performance. Iām wondering if playing with the nblocks configuration would help a bit more?
If your cpu is i9 13900(x) that has P cores and E cores you can try to set ecores=āfiltersā and multicore=ā1ā, on my i7 14700 this helps a lot
Wow! ecores=āfiltersā just learned about this! Many thanks 
I found that āecores=poolā spreads the cpu load nicely and more evenly than =filters on my i7 13700 cpu. Using htop on your machine you can see it. Tried ecores=filters too, Iām sticking with pool for now and multicore=1.
This is the description for ecores:
default : Default (normal) core allocation
pool : E-cores are allocated for generic DSP processing pool
filter : E-cores are allocated for rate conversion filters