It is now temporarily available on that server.
Thank you! Back up and running again as normal. Appreciate your help Jussi.
Itâs a shame about the Cuda 13 Compatibility through, between 5.14 and 5.15 of HQPlayer.
As otherwise V100 been handing every combination i have thrown at it so far. I completely understand the need to keep up with the SDK.
Once again thank you.
Al
Im sorry, obviously I meant HQPlayer OS.
Oh, meaning you canât build hqplayer from sources if sdk is not familiar with the posix environment. And hqplayerd binary is not the same from the embedded version. You have to make your OS debian/ubuntu/fedora compatible so basically it will be embedded version with a minimal install.
Do you have ACPI disabled in grub with Hqplayer OS ?
My new box is giving me some annoying messages in DietPi
[ 100.647417] ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.PEG1.PEGP._DSM.USRG], AE_ALREADY_EXISTS (20240827/dsfield-184)
[ 100.647420] ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20240827/dswload2-477)
[ 100.647421] ACPI Error: Aborting method \_SB.PC00.PEG1.PEGP._DSM due to previous error (AE_ALREADY_EXISTS) (20240827/psparse-529)
In HQPlayer OS it does not. It can be also because of Nvidia drivers⌠and since HQPlayer OS does not support GPU, no errors are being shown.
OK, I see. It is not technically feasible thoughâŚ
No, HQPlayer OS has itâs own specific build environment. And Nvidia doesnât support it, hence the two donât work together.
There is no point in making HQPlayer OS compatible with any regular Linux distribution, because then you can as well just install such distribution and the already offered Embedded package on it. It would mean I would lose control over my own OS.
No, modern PCâs wouldnât work without ACPI.
Buggy ACPI BIOS implementations are more rule than exception. The system may still end up being relatively stable as long as the bugs are not too bad. Linux kernel has some sanity checks for the ACPI information and thatâs why it complains, depending on log levels.
Different kernels may also have different workarounds for some known ACPI issues.
Some motherboard manufacturers have better BIOS developers while some others donât.
Just to mention that here, too: I had bought the Tesla P100 (Pascal architecture) because I wanted to use sinc-MGa at DSD512 (with ASDM7EC-super). Since then, I also bought a new DAC, and on that DAC, sinc-MGa isnât my favourite anymore. I had automatically assumed that the graphics card I used before (RTX 2060) wouldnât work with CUDA 13, too, or else wouldnât be up to the task of DSD512 with most filters. Now I actually looked and found that both assumptions were wrong. RTX 2060 is Turing architecture and thus still supported. While sinc-MGa doesnât work at DSD512, most filters do, including the sinc-Lh I prefer with my main headphones (HEDD2).
So Iâm back on the current version now without the need to buy a new PC.
And I must say itâs quite cool what is possible with a meagre i7-7700 + RTX2060.
I used to run hqplayer on a i5-7600k with a GTX1080 and it was quite impressive.
The loss of support for older cards left me with the choice of donât update hqplayer or build a new hqplayer machine. I ended up building a new machine.
Iâm now using a 14900k and it does everything and more the previous build did and it doesnât need the cuda offload.
Actually, Iâm getting a new computer now, too.
An unexpected influx of money made it possible, will be an i9-14900K, too. Iâll probably get it on Tuesday or Wednesday. Yay!
? 2025/11/19 21:42:33 clStreamReaderHTTP::WaitRead(): timeout!
? 2025/11/19 21:42:38 clStreamReaderHTTP::WaitRead(): timeout!
? 2025/11/19 21:42:46 clStreamReaderHTTP::WaitRead(): timeout!
? 2025/11/19 21:42:50 clStreamReaderHTTP::WaitRead(): timeout!
? 2025/11/19 21:42:59 clStreamReaderHTTP::WaitRead(): timeout!
After relocating my ROCK, I startet to get music droppings, specially when liseting to stream music (Tidal), but not when playing local files. I changed the ethernet cable and rebooted the ROCK and I the problem has gone. Could this had been related to the cable then?
That is possible yes. Best to use a regular office CAT6A (500 MHz) U/UTP cable for any audio use. And inexpensive to replace if necessary. These are good up to 10 Gbps.
Shielded cables are best avoided, since they may carry ground currents, spoiling the galvanic isolation Ethernet otherwise has. Ground currents can cause interference on the data transmission too, resulting in errors and packet loss.
Reason could be also as simple as less than perfect connector attachment, or slightly too much opened twisted pair at the connector ends. Smaller the connector, less the twisting needs to be opened. It shouldnât be opened more than about 10mm length. 500 MHz cables have tighter twist than 250 MHz ones.
Iâve been following your advice for years, I was using UTP cable thatâs included on tplink router, and donât know why, then I changed it for a blue jeans utp cat-6 (similar to the one before but shorter) and the issue was solved! Maybe that one came defective ![]()
Yeah, usually they include the cheapest they can source. And typically those are CAT5e or CAT6, not the CAT6A.
Unfortunately, Iâm rather disappointed by the performance of my new i9-14900k. While it works at DSD512 with ASDM7EC-super, poly-sinc-gauss-long, and DAC correction (Cyan 2), my preferred sinc-Lh doesnât even run reliably without correction with default settings. Only when I set nblocks to rather high values (32, 64) I get stable audio (still without correction!). Setting multicore to auto or 1 doesnât seem to make much of a difference. With ecores set to filter, itâs not possible at all to use sinc-Lh without dropouts.
With correction enabled, the best I could achieve with sinc-Lh and 7EC-super was a dropout every 5s or so. This is so far away from stable that my conclusion is that further tinkering makes no sense and this is only possible with the support of a graphics card. (I will test with my GTX2060 later today.)
Would you agree or do you think there are ways to get this running, say with BIOS tinkering or special kernels? Also, I havenât yet tested yet without the GUI being active.
Interestingly, when running stable without correction, the CPU doesnât even seem to be heavily loaded. The fan is blowing, but not at very high speed, and top only shows a load of ~12%. I know this isnât a reliable number, but still âŚ
Are my findings what is to be expected from a 14900k or could there be something wrong with my new system?
Please check the number of DSP pipelines.
I had similar problem - with 48kHz/24 files only, and sinc-Lh filter.
For reasons I do not know, I had nr of DSP pipelines = 8.
Reducing to 2 solved the issue.
I have a i9-13K900 with 32Gb memory. No GPU.
I upsample to DSD512, all sinc-Lh & ASDM7EC-super 512+fs.
No dac correction.
Dirk
Thanks for your reply!
Do you mean the pipelines in the Matrix tab? There are two only here. BTW, neither speaker processing nor convolution are active.
EDIT: The pipelines value in the engine tag is also set to 2.
The overall load percentages are misleading at best.
Letâs simplify things by assuming you would have a single core hyperthreaded CPU. So it would have two hardware virtualized CPUs. If only one of the threads would be fully loaded the total load shown by OS would be 50%. If both threads would be fully loaded, the total load shown by OS would be 100%. However, doing processing work for one second of audio would take same amount of time in both cases, since you have only one execution unit.
Hyperthreading only offers performance benefit when you have multiple processes/threads running per CPU core. In this case, it helps halving the context switching overhead of the multitasking OS, since the number of task execution switches the OS kernel needs to do is reduced by factor of 2.
In 14900K you have 8 P-cores that are hyperthreaded, so these appear as 16 virtual cores. Plus you have 16 E-cores that are not hyperthreaded. So you have total of 24 physical cores and 32 virtual cores. HQPlayer understands this and assigns tasks to the hardware correspondingly. From OS total load percentage point of view, the OS considers having 32 equally powerful cores (which is of course not the case in reality).
For E-cores, using sinc-long-h may be more beneficial. Although it may not work (I have not tested).
haalo
i test
yes
expected without cuda and the filter of lh u wish to reach
Youâre right, sinc-long-h works at least mostly on the e-cores, even with DAC correction. I had a few dropouts every few minutes, and once it became worse and worse with pauses of several seconds, more pauses than music, until I stopped the music and started it again. After that it was stable for more than five minutes, though. 96 kHz content has dropouts roughly every 30s.
This possibly has the potential to work with some more optimisations.
But for now I guess Iâll use my 2060 with sinc-Lh + correction, which does work reliably without dropouts.
@zottel for sinc-Lh use case, let me share my benchmark for you to may be concider if Sinc-Lh is your goal. Hardware is 14900KS + 4090. System handles with DAC correction. I would say CPU is not too far off from yours in this use case, GPU is far off. Sinc-Lh needs GPU memory. Here couple of images:
This is on stock settings, no OC. for 2ch listening you see only two cores at max out, but equally 70+ %% is as far as it goes, so for your CPU you should have this space allright
this is nVidia stats, 4090 is running at 75-90W, 25-50%% GPU utilisation, with 4GB constant vRAM, this is about what it takes. Clearly no need for 4090 if Sinc-Lh is a goal, but decent new 5th gen 8GB nVidia may be appropriateâŚ
PS: this is Sinc-L = âThe Beastâ filter with DAC Correction at SDM@1024 with 44,1 source, if anyone wonders
CPU is relatively OKâish⌠sometimes hitting 90% utilisation at 2 cores, but RAM is already nonsense⌠40Gb! and vRAM is insane, almost complete 24Gb!
But it works perfectly well with DC if it makes meaning for anyone. It is a good filter for some specifics. Try solo violine, wont be disappointed.
PPS: modulator is 7EC-fast 512+fs here and above.
Sounds also a bit like thermal throttling. How is the CPU cooling?



