Good, that’s the kernel system messages (dmesg output).
I don’t see any issues about link down there and this is all normal output, nothing notable. If the stutter/drop happens again, I’d be interested to the see the dmesg output again right after it happens.
Are you perhaps running out of RAM? What does “dmesg” say?
Was the first playback only local content, but with Roon radio also from streaming services?
If Roon cannot pass data fast enough to HQPlayer, you may get something like that. For streaming services it also means it needs to get the data fast enough from the cloud CDN.
Indeed, HQPe is running out of memory when doing 44.1 → 512x48 with poly-sinc-xtr-short-lp. 32Gb. Yet 48 → 512x44.1 and all other variations max out < 4Gb.
Once triggered, it sits for about 30 secs at the typical ram rates of < 4Gb and then starts spiraling out until all 32GB ram is used. Something doesn’t seem right. Why only poly-sinc-xtr-short-xx with 44.1 → 512x48 and not any other ratio or filter?
Yes, sounds normal. I wouldn’t recommend trying to run such single stage conversion. Even if you get the conversion up, it will likely have a plenty of dropouts.
It depends on the filter and conversion ratio. poly-sinc-gauss and poly-sinc-ext2 are two stage filters and hence avoid this issue.
Likely you get same result with other poly-sinc-xtr filters as well.
Hmmm ok, yes it looks like this happens with all 4 of the poly-sinc-xtr filters … --lp, -mp -short-lp, and -short-mp. the non-short ones do start but they have dropouts.
I don’t understand why 48 → 512x44.1 works without issue and uses such little ram? I would have thought that the math/process is pretty much identical, just a different non-integral ratio.
(Reason I am trying this is that my new DAC has dust pops when switching between 512x44.1 and 512x48. So wanting to fix the output rate. Guess I’ll go with 512x44.1 or use the -2s poly-sinc-xtr-short-xx-2s).
Sounds like members are having intensive discussions regarding network switches and SFP modules.
@jussi_laako
My question tonight is how HQP handles the “loss” associated with the PCM-to-SDM conversion.
My understanding is that it is inevitable to incur some loss during the conversion, but I believe you handle it cleverly. Could you explain your method(s) in simple terms so I can get a sense of it/them?
Thanks in advance!
The first playback was on 44/16 qobuz content then when I introduced some higher res content the problems started but mainly when the resolution changed upwards but then they persisted as I used lower resolution like internet radio. Problems were even worse when I tried local content.
Today I have done a whole system switch off and restart which resulted in Roon not being able to recognise hqp server so I deleted hqp server and reinstalled it but it does not recognise my key and I don’t wish to use a trial version. I have emailed you separately about this. The problems seem to occur when changing formats within a playlist. The only way I have been able to force the problem is by putting together a playlist of varying formats and sure enough halfway in it starts stuttering. The first time I left it playing and it cleared for the next track but then it soon started again and became much worse so that I had to stop it altogether. I am unsure where to go next but if I get it up and running I shall induce the problem and then get a log from the server as the problem is occurring and see if anyone ( Deano ?) can read anything useful from that.
Thanks
No, there’s no “loss”. For fun, I did try converting 192/24 PCM source to DSD and back, bit-perfect.
Point of the whole thing is to avoid losses at the DAC by always using a format the DAC performs best at. And also to fix errors in the source data and DAC. Plus you can of course also correct some of the headphone and loudspeaker/room acoustic errors as well.
1 Like
hi @jussi_laako just following up on this. Curious as to what makes 44.1 → 512x48 with poly-sinc-xtr- spin out with tens of GB of ram usage, whereas 48 → 512x44.1 spins up quickly and with little ram overhead. Is is simply because of the conversion ratio? They are both non-integral and of similar scale.
Yes, 44.1k family to 48k family is quite a bit bigger operation than 48k family to 44.1k family. Luckily, since latter is the normal use case.
44.1k family to 48k family is no problem for something like 44.1k to 768k. But from 44.1k to 24.576 MHz is a different matter.
If you’d like to do the conversion you are describing, I would recommed to use the -2s filter. It will consume much less resources and give better quality as well.
Ok thanks. Very interesting. Seems so similar on the surface.
Didn’t know that the -2s variants gave better quality than the single stage filters. I mistakenly assumed that the 2 stage conversion was a trade-off of performance vs quality. I guess you keep the original single stage filters around just in case someone prefers them for some arbitrary reason.
Yes, I try to avoid removing anything… The quality difference is not big, and well below any physically possible analog noise floor by three figure number of dB, but it is there. Depends on the factor, so the difference is smaller for example for 128x compared 512x.
The second stage filters are special ones designed for the particular purpose, but technically not any worse than the first stage ones. So no trade-off being made there.
With -2s you get 44.1k to 384k first and then 384k to 24.576M. With gauss and ext2 you get 44.1k to 768k and then 768k to 24.576M.
As another example; with -2s you get 176.4k to 1.4112M first and then to 24.576M. And with ext2 and gauss you get 176.4k to 2.8224M first and then to 24.576M.
2 Likes
Thank you very much!
I can use HQP with more confidence. 
This is loosely related to HQP, but I decided to swap the motherboard and CPU on the MSI (currently Fedora 42 with HQPe and Windows 11 – dual boot) and ASRock (currently Windows 11 with roon core) motherboards.
ASRock has RGB control in the BIOS, and I want to adjust the VRM fan’s lighting using it, because the HQPe case is a Fractal Design 7XL with tinted glass on one side and the lighting inside is visible.
The VRM fan is from Arctic Liquid Cooler III 420 A-RGB, and the fans have been swapped for FD Momentum 14 fans, controlled by the Adjust Pro Hub, which can store configurations in its built-in memory. The Arctic VRM fan’s default lighting isn’t terrible, but it’s not my taste either, so I just want to change this one thing. I tried OpenRGB, but it seems to conflict with the Pro Hub, and I couldn’t do anything. 
I have Fedora 42 and Windows 11 installed on separate M.2 storages, so I hope the swap will go smoothly without much trouble. I also have the HQPe dongle, so that should be fine.
Hopefully I can work on it some time soon, before I step into a busy month for work.
Update… this only happens on Ubuntu Server LTS. DietPi with default kernel or with jl+ debian kernel is ok … same fingerprint regardless of BIOS firmware version, hardware enabling/disabling etc. I thought this weird behavior could be related to the engineering sample Xeon 8480+ CPU, so i swapped it with a retail version of Xeon w7… same thing, on DietPi its fine, on ubuntu its going rampage …
Have you tried Fedora Server 42?
Nope, i will try HQPayer OS today
How do I re-login when I have trouble accessing certain pages on the HQPe web control?
For some reason, I have the above issue on my regular Windows 11 computer.
Either from Google Chrome or Firefox, I fail.
Somehow, from iPad, I have full access.
What is the likely cause?
In which of the cases you are entering your username and password?