Best CPU for hqplayer

[nounouchet]

I installed HDPlayer on Rpi5 from a Raspberry Pi OS Lite 64 bits image and it works fine.
I had a USB cable which was not compatible with Rpi4 and which now works with Rpi5!
Thanks to jkelly for all the commands.

@jkelly what does "Original install process by bipet" mean?

[jkelly]

54 minutes ago, nounouchet said:

I installed HDPlayer on Rpi5 from a Raspberry Pi OS Lite 64 bits image and it works fine.
I had a USB cable which was not compatible with Rpi4 and which now works with Rpi5!
Thanks to jkelly for all the commands.

@jkelly what does "Original install process by bipet" mean?

Giving credit to user bipet for the original version of this script, which I edited to work on the RPI5.

[Miska]

12 hours ago, nounouchet said:

whereas HQPlayer OS Embedded 5, which is based on the same distribution, does not work with Rpi5.

 

No, HQPlayer OS is not related to bookworm or RPi OS in any way.

 

12 hours ago, nounouchet said:

So there is a checking done on the Rpi version in HQPlayer?

 

No, but I've explained this earlier. On ARM based platforms due to lack of ACPI and similar features, the OS needs to have prior knowledge how and where every pin of each chip on the board is connected. Without this pre-programmed knowledge, the OS cannot boot on the particular board. And each RPi board version is different. For example there are four different board variants of RPi4 which each require such prior programmed knowledge of all connections. HQPlayer OS doesn't have all this yet for RPi5. In addition HQPlayer OS uses different bootloader than RPi OS.

 

So on ARM based platforms don't work like PC where the ACPI facilitated by the BIOS describes hardware connections of each board.

 

12 hours ago, nounouchet said:

Can I find somewhere a procedure to install Debian 12 "bookworm" + HQPlayer Embedded 5 on a Rpi ?

 

It is described on my web page. The base expectation is that one is familiar dealing with Debian based Linux distributions.

 

[nounouchet]

OK thank you Jussy,

I'm a little hard of hearing but ultimately everything works.

I'm looking forward to HQPlayer OS for Rpi5!

[Miska]

I just tested HQPlayer Embedded more on RPi5 trying to get DSD256 working with default settings. I first overclocked CPUs to 3 GHz, but that wasn't stable on my unit. Then I dropped it to 2.8 GHz and that is stable. Especially ASDM5EC-light is close to working. Then I increased clocks to 2.9 GHz which is also still stable. With this, ASDM5EC-light drops out maybe once per minute. So it is pretty close to working on RPi5. But it still doesn't quite work.

 

Maybe with some fine tunings it could start working, it is not far!

 

Doing these kind of overclock needs serious cooling as well, Pi starts to run pretty hot! This was tested on GeekWorm passive cooled case.

 

Note! You really need a proper 27W RPi5 USB Type-C PD PSU for these kind of things. With the RPi4 5V 3A PSU the, the overclocked Pi was freezing really quickly when doing anything. With the 27W RPi5 PSU it was running perfectly fine.

 

[ManfredHQ]

On 1/11/2024 at 8:09 PM, Miska said:

I just tested HQPlayer Embedded more on RPi5 trying to get DSD256 working with default settings. I first overclocked CPUs to 3 GHz, but that wasn't stable on my unit. Then I dropped it to 2.8 GHz and that is stable. Especially ASDM5EC-light is close to working. Then I increased clocks to 2.9 GHz which is also still stable. With this, ASDM5EC-light drops out maybe once per minute. So it is pretty close to working on RPi5. But it still doesn't quite work.

 

Maybe with some fine tunings it could start working, it is not far!

 

Doing these kind of overclock needs serious cooling as well, Pi starts to run pretty hot! This was tested on GeekWorm passive cooled case.

 

Note! You really need a proper 27W RPi5 USB Type-C PD PSU for these kind of things. With the RPi4 5V 3A PSU the, the overclocked Pi was freezing really quickly when doing anything. With the 27W RPi5 PSU it was running perfectly fine.

 

Hello have a look at morefine Nuc they less expensive in AMD mode and for 450$ you have the best 

 

This is mine 

 

https://morefine.com/fr-fr/products/morefine-m600-mini-pc-amd-6900hx-6800u-6600u

 

Manfred

[Miska]

Small update regarding RPi5.

 

With some settings fine tuning I was able to get ASDM5EC-light working reliably to DSD256 output. And ASDM7EC-light also such way that there's only about one drop-out per five minutes. This with overclocking to 2.9 GHz. If one can get a particular unit running stable at 3 GHz, then ASDM7EC-light may also become stable.

 

[dBc]

You are using one core per audio channel, right?

[Miska]

18 minutes ago, dBc said:

You are using one core per audio channel, right?

 

Since RPi5 is quad core, two cores per channel.

 

[AudioDoctor]

@Miska Your efforts with the Pi5 are amazing!

[Carousel]

@Miska Is it technically possible to upscale a PCM 24-48 source file to DSD256 using sinc filters like sinc-M or sinc-Mx? My set-up can do a 16-44 source file, but not a 24-48 source file. If it should be doable, then that could be an argument for my upgrading from an 8GB 4060 Ti to a 12GB 4070 Ti. If it is not doable, then there is no point. Note: I was using ASDM7ECv3. But DSD5 and 7 did not work either. My CPU is a 14700K. Thanks.

[Miska]

47 minutes ago, Carousel said:

@Miska Is it technically possible to upscale a PCM 24-48 source file to DSD256 using sinc filters like sinc-M or sinc-Mx? My set-up can do a 16-44 source file, but not a 24-48 source file. If it should be doable, then that could be an argument for my upgrading from an 8GB 4060 Ti to a 12GB 4070 Ti. If it is not doable, then there is no point. Note: I was using ASDM7ECv3. But DSD5 and 7 did not work either. My CPU is a 14700K. Thanks.

 

You can instead use practical equivalent poly-sinc-ext3 which can convert between rate families.

 

[bogi]

49 minutes ago, Carousel said:

Is it technically possible to upscale a PCM 24-48 source file to DSD256 using sinc filters like sinc-M or sinc-Mx? My set-up can do a 16-44 source file, but not a 24-48 source file.

To understand this behavior, you need to look into chap. 4.5 of HQPlayer 5 Desktop manual, which is installed together with application files. You can find that these sinc-* filters contain 'integer' in the 'ratio' column of the filter table. It means these filters allow only integer upsampling ratio. For example then you are upsampling from 44.1k to DSD256 (44.1*256=11.29MHz), the upsampling ratio is 256. But when you are upsampling from 48k to 44.1*256, upsampling ratio is non integer and therefore HQPlayer refuses to perform the operation. No hardware update helps on that.

 

What could help you is a DAC which supports so called 48k based DSD rates, for example 48*256=12.28 MHz. Otherwise the only possibility for you is to use a more or less similar filter which allows any conversion ratio, like poly-sinc-long-lp-2s, poly-sinc-ext3, poly-sinc-hb-l, poly-sinc-gauss-long. Worth of try could be also middle length filters like poly-sinc-hb-m, poly-sinc-lp-2s and with hires material poly-sinc-gauss-hires-lp.

[Carousel]

Aha! Thank you both. I knew that the 2^x filters like closed-form were a problem here. And I had looked in the manual. Forty-eight is an integer. But, yeah, not an integer ratio multiple of 44.1! I am with you now. With your help I am getting closer. The 14700K plus the 4060 Ti seems to be working for me in stereo, for what I want to do with my stereo DAC. I am just moving on to my surround sound DAC now. The exaSound S88 is ESS9038PRO based. Just trying now, ticking 48K DAC in HQP does not seem to make it into one though! Using poly-sinc filters for 8-channels is not a problem into DSD256 though. I guess I can stick with what I have. A sad day for an electronics shopping addict. 

[bogi]

25 minutes ago, Carousel said:

ticking 48K DAC in HQP does not seem to make it into one though!

To have it really tested, you need yet to set max. DSD rate in HQPlayer settings to 48k based one and also I recommend to set [x] Adaptive rate which switches output rate between 44.1k and 48k families according source rate. Then try to play 48k based content. If it does not work, just undo these changes.

Maybe there is an exaSound S88 user who could tell you if 48k based DSD rates work with that DAC.

[Carousel]

Seems to be a no-go for 48K on the S88. Glad to to take any exaSound expert pointers though. Maybe I just maxed some other parameter in the mix...

 

Back on 44.1 DSD only, I just found the surround limit of my 14700K + 8GB 4060 Ti system. Upscaling 5-channel 24-96 to DSD256 using sinc-medium is bouncing around 95% of GPU utilization with occasional glitching. Not sure this justifies trading up to a 4070 Ti though...

[Miska]

1 minute ago, Carousel said:

Back on 44.1 DSD only, I just found the surround limit of my 14700K + 8GB 4060 Ti system. Upscaling 5-channel 24-96 to DSD256 using sinc-medium is bouncing around 95% of GPU utilization with occasional glitching. Not sure this justifies trading up to a 4070 Ti though...

 

Using one of the poly-sinc filters gives you lighter load. For example any of the -2s ones or ext2/ext3/gauss for example.

 

Now that 4070 Ti Super is out, worth checking it instead of regular 4070 Ti. Since the new Super-one increases RAM from 12 to 16 GB and boosts performance overall. Becomes available on Jan 24th.

 

[littlej0e]

First, @Miska - thank you so much for all the useful information you've posted here, and in other forums. It is greatly appreciated. I've taken so much information and inspiration from you for my server builds.  

 

Second, I just finished building an HQPlayer 5 rig for DSD1024 using a new 14th gen Intel 14900K and thought I would provide some initial feedback. I compared the following software/OS configurations using identical hardware, BIOS and HQPlayer 5 settings:

• EuphonyOS + HQPlayer 5 Embedded (w/latest updates)
• Windows Server 2019 (w/latest MS updates tested with, and without, Audiophile Optimizer) + HQPlayer 5 Desktop
  • HQPlayer 5 Settings:
    • 1x Oversampling
      • poly-sinc-gauss-hires-ip
    • Nx Oversampling
      • poly-sinc-ext2
    • Modulator
      • ASDM7ECv3
    • Bit rate
      • Auto
    • Rate limit
      • 45158400 (DSD1024)

The Euphony build wiped the floor with Windows Server 2019 in raw performance...by a wide margin. There were major processing limitations using WS2019 that resulted in max rates of only DSD256 without drop outs (DSD512 was very close, but not quite 100% drop-free). Meanwhile, Euphony + HQP5 runs flawlessly without dropouts all the way up to DSD1024. What gives?!?

 

I did extensive testing with various configs, but I couldn't fix the dropouts at DSD512. I tried literally everything I could think of: defaulting/optimizing BIOS, Windows, Process Lasso, drivers, settings, etc., etc., but nothing fixed it. This leads me to one of three possible conclusions:

1. I majorly screwed up the WS2019 config. 
2. Real-time Linux kernels, such as those used in EuphonyOS, make an enormous difference in latency and subsequent upscaling performance.
3. Windows, HQPlayer, drivers, etc. are individually or collectively bugged to hell, preventing normal operation. 

No 3 seems incredibly unlikely for many reasons, which just leaves 1 and 2. Has anyone had similar experiences with WS2019 and/or know what could be gimping it? Or did I accidentally stumble upon the processing/upscaling limitations of the Windows NT kernel?

[Miska]

5 hours ago, littlej0e said:

I did extensive testing with various configs, but I couldn't fix the dropouts at DSD512. I tried literally everything I could think of: defaulting/optimizing BIOS, Windows, Process Lasso, drivers, settings, etc., etc., but nothing fixed it. This leads me to one of three possible conclusions:

1. I majorly screwed up the WS2019 config. 
2. Real-time Linux kernels, such as those used in EuphonyOS, make an enormous difference in latency and subsequent upscaling performance.
3. Windows, HQPlayer, drivers, etc. are individually or collectively bugged to hell, preventing normal operation. 

No 3 seems incredibly unlikely for many reasons, which just leaves 1 and 2. Has anyone had similar experiences with WS2019 and/or know what could be gimping it? Or did I accidentally stumble upon the processing/upscaling limitations of the Windows NT kernel?

 

Where does the output go and how?

 

I have never used Euphony, so for example I don't know which of my HQPlayer builds you have there. So not really sure what the comparison is against.

 

I have no trouble doing DSD256 output on my laptop with AMD 5900HS CPU, or DSD512 on my Windows test machine with i9-10900K. Both of these run stock Windows 11 Pro, just Power Profile set to High Performance. Nothing else.

 

Some potential issues:

• Different Multicore DSP setting
• ASIO buffer size set to too small
• WS2019 install missing some components used by HQPlayer
• Any changes made to the stock OS
• If WS2019 doesn't understand the 14th Gen CPU (you could check HQPlayer log for this)
• WS2019 itself

 

One notable thing is that Windows Server is opposite of any OS running realtime kernel. Server kernels are tuned for just maximum processing and I/O throughput performance. This comes with cost of poor response times. Windows Desktop kernels are tuned for maximum multimedia/gaming performance and best response times. Realtime kernels are tuned for response times at the cost of processing and I/O throughput performance. These two are mutually exclusive from OS tuning point of view.

 

On Linux you can easily install a low latency or realtime kernel on a server OS. Not so on Windows.

 

Low latency kernel is blend between the two, not trading as much processing / I/O performance while keeping response times low.

 

But for Windows, I would suggest starting with stock Windows 11 Pro and setting Power Profile to High Performance. Or with stock Windows 11 for Workstations and setting Power Profile to Ultimate Performance. Do not touch the OS otherwise.

 

In ASIO driver control panel, set the buffer size to maximum and enable "Safe mode" there, if such exists (it is in Thesycon sourced drivers). Leave "Buffer time" in HQPlayer to "Default" so it will use the size suggested by the ASIO driver.

 

[Miska]

I believe Windows Server editions by default install are also missing some multimedia related services. So all the things HQPlayer is trying to do to have proper performance may not exist. These are by default installed and enabled on Windows Desktop editions.

 

[littlej0e]

2 hours ago, Miska said:

 

Where does the output go and how?

Linux: Roon > HQPlayer 5 Embedded > EuphonyOS (arch Linux kernel 5.18) > Intel Optane 900P (boot drive) > Asus Z760-P Prime (i9 14900K) > JCAT XE USB PCIe card > USB-A to USB-B cable > T+A DAC 200 > dual 3-pin XLR cables > Pass X250.5 amp. 

 

Windows: Roon > HQPlayer 5 Dekstop > Windows Server 2019 > same hardware chain

 

2 hours ago, Miska said:

I have never used Euphony, so for example I don't know which of my HQPlayer builds you have there. So not really sure what the comparison is against.

 

Euphony is an arch-based Linux OS built specifically for audio (very similar to AudioLinux, if you are familiar). Here is a screenshot:

 

According to the screenshot, I'm running HQP 5.0.0 Embedded. It appears to be running wonderfully as configured.

 

You can also choose between different Linux kernels and versions of HQPlayer:

 

 

 

2 hours ago, Miska said:

I have no trouble doing DSD256 output on my laptop with AMD 5900HS CPU, or DSD512 on my Windows test machine with i9-10900K. Both of these run stock Windows 11 Pro, just Power Profile set to High Performance. Nothing else.

It appears the simplest answer is indeed the correct one lol. Clearly "less is more" when building a machine specifically tuned for upscaling. 

 

2 hours ago, Miska said:

Some potential issues:

• Different Multicore DSP setting
• ASIO buffer size set to too small
• Any changes made to the stock OS
• If WS2019 doesn't understand the 14th Gen CPU (you could check HQPlayer log for this)
• WS2019 itself

One notable thing is that Windows Server is opposite of any OS running realtime kernel. Server kernels are tuned for just maximum processing and I/O throughput performance. This comes with cost of poor response times. Windows Desktop kernels are tuned for maximum multimedia/gaming performance and best response times. Realtime kernels are tuned for response times at the cost of processing and I/O throughput performance. These two are mutually exclusive from OS tuning point of view.

 

Appreciate the education. That certainly matches what I'm seeing trying to upsample on this particular build of WS2019. I always see two random p-cores getting pegged, or close to pegged, in both WS2019 and EuphonyOS,. But Euphony just keeps smiling and spitting out DSD1024 goodness, while WS2019 curls up in the fetal position and drools on itself. I am going to re-install WS2019 and test again. It seems highly likely I screwed something up.  

 

2 hours ago, Miska said:

On Linux you can easily install a low latency or realtime kernel on a server OS. Not so on Windows.

 

It seems realtime kernels are the better choice for higher (see ludicrous) DSD upsampling rates. This is/was news to me as I didn't truly grasp how some of the differences between Linux and Windows would actually translate in practice with audio server builds. 

 

It sure is nice to be able to learn from all the smart folks around here ;-)

 

2 hours ago, Miska said:

Low latency kernel is blend between the two, not trading as much processing / I/O performance while keeping response times low.

 

But for Windows, I would suggest starting with stock Windows 11 Pro and setting Power Profile to High Performance. Or with stock Windows 11 for Workstations and setting Power Profile to Ultimate Performance. Do not touch the OS otherwise.

 

Interestingly, this is where I saw the best Windows performance with HQP5. I tried HQP5 on my work rig (AMD 5950X on Win 11 Pro), just to get a notional baseline of performance. It ran quite well without any dropouts up to DSD512 using the same filter/mod settings mentioned in my first post. This is obviously anecdotal, but I found it interesting nonetheless. This told me something had to be wrong (or missing) with my WS2019 configuration. 

 

2 hours ago, Miska said:

 

In ASIO driver control panel, set the buffer size to maximum and enable "Safe mode" there, if such exists (it is in Thesycon sourced drivers). Leave "Buffer time" in HQPlayer to "Default" so it will use the size suggested by the ASIO driver.

 

I tried this, along with many other buffer settings, but none made a difference. I even tried swapping the T+A ASIO driver with some 3rd-party drivers. But none were as good as the T+A driver and tended to cause far more problems than they solved. 

 

Thanks for the correct buffer setting!

 

2 hours ago, Miska said:

I believe Windows Server editions by default install are also missing some multimedia related services. So all the things HQPlayer is trying to do to have proper performance may not exist. These are by default installed and enabled on Windows Desktop editions.

 

 

Ultimately, it seems No. 1 was the correct answer; I mis-configured Windows Server 2019 by omission. Your experience running DSD512 on your test machine all but confirms this. 

 

I always hate using Windows Desktop for audio builds because it ships with so much unnecessary bloat. I have to spend time chopping the ISO to pieces before I even create a bootable USB. That's the primary driver behind using Windows Server editions - less bloat by default = less effort needed to kill and cleanup unneeded crap. But it sounds taking the time to carve up Win 11 Pro might be worth it. I'll do that and compare results against WS2019. 

[Miska]

26 minutes ago, littlej0e said:

Euphony is an arch-based Linux OS built specifically for audio (very similar to AudioLinux, if you are familiar).

 

Yeah, I'm aware of these, but I don't use these personally and those are not among my officially supported distributions.

 

26 minutes ago, littlej0e said:

According to the screenshot, I'm running HQP 5.0.0 Embedded. It appears to be running wonderfully as configured.

 

That's a bit oldish, the latest is 5.3.2.

 

But it doesn't answer to my question which build of HQPlayer is used there, just curious for comparison purposes.

 

[littlej0e]

10 minutes ago, Miska said:

That's a bit oldish, the latest is 5.3.2.

 

But it doesn't answer to my question which build of HQPlayer is used there, just curious for comparison purposes.

 

 

HQP5E appears to be installed as "generic build" version 5.0.0 (see screenshot)? Perhaps the Euphony folks test specific versions of HQP to passively ensure compatibility (presumably to prevent a flood of help tickets)? 

 

 

Would you like me to send you the log file?

[Miska]

1 minute ago, littlej0e said:

HQP5E appears to be installed as "generic build" version 5.0.0 (see screenshot)? I assume the Euphony folks test specific versions of HQP to passively ensure compatibility and presumably prevent a flood of help tickets. 

 

That just tells it is not a custom OEM build. But a regular release build.

 

At the moment I make following builds of Embedded:

• Two different x64 builds for Ubuntu 22.04 LTS
• One x64 build for Fedora 37
• One x64 and one arm64 build for Debian 12
• Two x64 and one arm64 (RPi4) build of HQPlayer OS

It is one of these, but not sure which one first three lines.

 

[littlej0e]

42 minutes ago, Miska said:

 

That just tells it is not a custom OEM build. But a regular release build.

 

At the moment I make following builds of Embedded:

• Two different x64 builds for Ubuntu 22.04 LTS
• One x64 build for Fedora 37
• One x64 and one arm64 build for Debian 12

 

What information can I check or send to answer this question for you? Unfortunately, Euphony blocks shell access.

 

42 minutes ago, Miska said:

• Two x64 and one arm64 (RPi4) build of HQPlayer OS

 

I had no idea you supported Fedora, or more importantly...wrote your own OS for HQPlayer!!! Shows what I know.

 

I just finished tumbling down the rabbit hole a bit and found the hqplayerd image directory. I'm downloading as we speak and will install shortly. I can't imagine a better fit for this use case! Plus, Roon is basically dead processor cycles anyway - lol.