camott

Thanks for noting that. Going to update BIOS today.

Other than an academic exercise, why wouldn't you just install the low-latency kernel instead of trying to achieve similar results with the generic kernel? do you think you can do better with finer tuning?

So what is the difference between the 6.8.x lowlatency kernel and the 6.8.x generic kernel with various permutations of the performance parameters? i.e. is there a way to configure the generic kernel such that it's effectively identical to the lowlatency kernel?

I updated Ubuntu using do-release-upgrade without issue and installed HQPE 5.7.1. Haven’t really noticed any performance differences yet, with either latest stock low latency kernel or with JL+.

Fyi you don’t need to install the libgmpris-dev and libgmpris-dbg packages. i upgraded with do-release-upgrade without a hitch - and even over ssh. Took about 10 minutes. I only use the box for HQP so wasn’t too worried about it going awry and having to do a fresh install. i haven’t really noticed any performance improvements yet, with or without the new JL+ kernel.

Likewise. With 14900k. But it was also like this with 5.6.x as well.

I also notice one other weird thing. In your screenshot it says "Detected Device = DAC200?" with a question mark next to it. Mine does not have a question mark.

In windows, my file has 252kb in explorer and if you right-click and open the properties for the file it says size=258005. I also just tried the elink update tool and it says "filesize=258005" when I start the same update. I then I get a dialog box asking me to proceed. So something is not right with the file you originally used imo ...

ok. wonder why it says "filesize = 263285" in your elink screenshot ... i can try getting mine setup to see if it does the same

Something is not right with the file you downloaded from the T+A site. When I download that update package/file, it's also 258005 there. i.e. the file is the same size, no matter if from GitHub or the T+ site. What is the size of the file in your unzipped folder from T+A site? ls -las DAC200_UP_V120/UPD_DAC_200_V_120.txt 504 -rw-r--r--@ 1 chris staff 258005 Mar 18 11:06 DAC200_UP_V120/UPD_DAC_200_V_120.txt

I have done this procedure several times and it looks like it's getting stuck verifying the firmware file - the file size says 263285 but the one I used from GitHub https://raw.githubusercontent.com/OE333/DAC200-HA200-Update-Tool/main/eXtended_Firmware_DAC200/UPD_DAC_200_V_120.txt has a length of 258005. How did you download the file?

You can no doubt see this as well, but when i enable metering client side an extra process(pid) gets added server side, and when i disable client side metering that pid never goes away. (Whereas with actual client connection, a new pid is created but dropped immediately after closing).

fwiw, did a bit more testing: 1. with normal buffer, buffer under-runs/dropouts occur consistently every 35 - 38 seconds once metering enabled. same frequency once disabled. 2. with short buffer, under-runs/dropouts occur every 11 - 13 seconds once metering enabled. same frequency once disabled. 3. changing filter/modulator settings in realtime via client does not fix it. restarting hqplayerd (either via systemctl or changing settings in hqpe) always resolves it. hope that helps you triage/fix the issue. will avoid using the meter for now.

Hi @Miska wanted to report a performance bug with HQPlayer5Client metering. I have tried to capture the issue in the attached video. Without metering enabled, the buffer (as represented by green bar) cycles in the top 20%, never going below say 80%. When metering is enabled (when the hqp track time gets to 0:40 secs in the video) , the additional process on the server side causes the buffer to start cycling down lower, resulting in a dropout whenever it gets to roughly 50% on the green bar (at 0:58 and 1:12 track time). Now, when I turn metering off (at 1:15 track time), the problem doesn't go away (at 1:28 and 1:44 track time). So it seems like whatever additional thread/process was enabled by metering is not being stopped on the server side. The only way for me to fix it is by restarting hqplayerd. I can accept that enabling metering is adding some small additional load on the server, but it would be very helpful if this additional processing could be stopped when metering is disabled. I know it's likely a very small change in overall performance but because I am running on the very edge of what's possible, it actually is the difference between dropouts or not in my case! Thanks! Screen Recording 2024-06-13 at 11.02.24 AM.mov

fyi, I am able to run Teamgroup t-create 2x16GB DDR5-7200 at 7400 with default XMP profile 1 without issue. This is on a ASRock Z790 Nova WiFi motherboard, which I very highly recommend for overclocking ram and cpu btw. It can also overclock my 14900k to 62/62/60/60/57/57/57/57 with all other default BIOS settings (it has a 20 phase VRM or something like that, not that I really know much about VRM). And a good AIO of course. This allows me to do all source rates including 192k with ASDM7EC-super @1024x48 + ext3 without a GPU.