HQPlayer Desktop thread

I’m still building a 14900k box, but cuda being deprecated still doesn’t make sense to me as by installing 5.14 offload works, and installing 5.15 offload is broke. Then uninstalling 5.15 and reinstalling 5.14 it’s fixed again.
Isn’t nvidia v580 driver with cuda 13 is still being utilized in both scenarios?

5.14 uses CUDA 12.9 and 5.15 uses CUDA 13.0. The driver is just an interface between software and GPU. Newer drivers facilitate newer interface functionality, including support for newer GPU models.

This is the driver version table from the CUDA release notes:

So they don’t promise driver 580 would work with CUDA 12.x applications. But it likely does.

1 Like

Ahh. Now that makes sense.
Thank you @jussi_laako
:musical_notes:

Does anyone has issues with hqplayer after updating to the latest version on macOS Tahoe?

If I pause and then play there will be a huge noise/distortion in the reproduction, my output is PCM 384 variable, I have been using this config for months only have issues after the OS and hqplayer updates, not sure if I should email @jussi_laako with a video demonstrating the issue.

just disabled “adaptive rate” but the issue persist, the dac is an Ares II. I tested several PCM sample rates but the issue persisted. Same thing with different filters (tested iir2 and the poly-sync-short-mp)

tested the output at 16, 20 and 24bits with same result, I always use it at 20bits as per Jussi’s recommendations. the issue persist with different shapers.

Passed Tahoe 26 this morning, HQP 5.15 with Naa, PCM 176.4/192 on Holo Spring 3 KTE.
No problems encountered

1 Like

My DAC is directly connected through USB

CoreAudio in Tahoe seems to have a bug… Not a first time, but previously such mostly happened on Intel silicon macOS after Apple released their own silicon.

Every second output device start seems end up messed up, doesn’t happen with the macOS 15.7 they released at the same time. I’m trying to figure a workaround.

If you have “Idle time” in HQPlayer set to 30 or 60 seconds and you use fixed output format, then it would be rather rare encounter.

2 Likes

thanks Jussi, I set the idle time to 60 and it is working with normality.

It happened once again this morning, it is a hazard to use headphones with this issue, I cannot use headphones now I will not risk my hearing. @jussi_laako

And with the new version (5.15.1) released recently too?

looks just got released, hope it fix it, it is baaad.

“Workaround for macOS Tahoe CoreAudio issue.”

Just cross-posting here some details I posted at AS, about the topic…

— 8< —

Just a note about the new poly-sinc-ext2 vs poly-sinc-gauss. These two filters are sort of pair, rather different but both very good. Now the poly-sinc-ext2 is offered as poly-sinc-gauss matching pairings. So for example poly-sinc-ext2-long and poly-sinc-gauss-long have same parameters to the extent reasonable, such as number of taps and fc. So you can compare the two head to head.

So if I try to simplify this to the extreme, poly-sinc-gauss* puts more emphasis on time domain, while poly-sinc-ext2* puts more emphasis on frequency domain. Although this is far from black-and-white, so neither one is bad on the other domain.

Already earlier one could have done this with for example sinc-Mx vs sinc-MGa.

— 8< —

This as explanation about the point behind providing the matching pairings.

1 Like

A question about NAA. I’m thinking of buying an LHY Audio RPI https://www.lhy-audio.com/products/rpi/ It has a Raspberry Pi 4 Model B inside, but it doesn’t say how many GB of RAM it has. The idea is to install NAA on its microSD card. If LHY has opted to reduce costs as much as possible and its RAM is 2GB (and it also has the OCXO clock soldered to the board and therefore the RAM cannot be changed), would those 2GB be enough for NAA? Thank you.

Based on the LHY Streamer’s description, I think the Ustars C19 is preferable (Model A with OXCO, or B without OXCO and external clock connection).
It’s a CM4 with 2GB that can be replaced if necessary.
I installed Naa 5.16 on it, so there’s no need to open and remove the microSD card.
In addition, it has AES, coaxial, and I2S ports, but only one USB port. I exited SDM 1024 without any problems
However, this USB port seems to handle better because it’s not the RPI’s direct USB output.
The price is similar, if not cheaper.

1 Like

Yes, 2 GB is fine for NAA use. Only with HQPlayer OS when running something bigger and heavier in HQPlayer Embedded you may need more.

Sorry, but I don’t understand the point about OCXO when using USB output… (USB doesn’t carry any audio related clocks)

1 Like

Exactly, there’s no point in an external clock for USB! It doesn’t add anything at all.

Now, I’m going to share my experience, and I’m still skeptical about the results, but Jussi might be able to shed some light on the matter…

I recently installed an external LHY 2S clock that I connected to my Mutec MC3 + USB (75 ohm and square). I also have a Holo Spring 3 KTE DAC.

I did some comparative listening between two different setups (on numerous tracks from 44.1 to 192 and DSD, of course, on the same songs at the same volume):
1/ Naa connected via USB to the Holo (SDM1024 and 8B filter and DAC correction)
2/ Naa connected to the Mutec via USB and Holo connected via coaxial to the Mutec (PCM output 176.4 and 192, NS9 and no DAC correction possible)

Well, in all cases, the difference is obvious and undeniable, the systematic victory of option 2/.
Lots of detail, space, better spatialization, more “life”—in short, everything is better!!!
I was 100% convinced of the superiority of DSD, but I have to admit that it is far surpassed by PCM; be careful with the configuration described above. So if technically the measurements indicate a superiority of DSD upsampling over USB, my listening reveals completely the opposite and in my case, PCM upsampling and external clock on Mutec are :):):):):):).

Did you take into account that PCM is 6 dB louder on Holo Audio? Do you have PCM gain compensation in HQPlayer set to -6 dB as it should with Holo Audio?

Objectively, overall reconstruction accuracy at 176.4/192k PCM rate is rather poor… Plus clocking suffers with S/PDIF (or AES/EBU or I2S).

Spring 3 has practically perfect clocks built-in, so nothing to be improved on that front.

With the external clock + DDC + Spring 3 you have two PLL based clock frequency conversions in the chain… (at least, maybe even three)

Thank you for your reply. I spent quite a while looking at it in detail after your message and discussing it with a friend. You installed NAA. Were there any compatibility issues? Aren’t USB drivers a bit special and could they cause problems? I also wonder if a CM4 board is better than a complete RB 4B like the one in the LHY. And the switching power supply versus the good internal power supply of the LHY. Did you put an external linear power supply on the Ustars? How is the quality of the components? Thank you for any information you can provide.

Thanks, Jussi. The idea is not to install HQPlayer on that device, but to use it as an NAA endpoint from the PC Audio with Roon Server and HQP5 Desktop. Is there any difference between your NAA OS for Raspberry when used with CM4 boards? Any drivers that don’t work? The LHY RPI I was asking about has a full Raspberry 4b, but @MilJL87 recommends the Ustars C19 https://es.aliexpress.com/item/1005007518706943.html which has a CM4 board.

As for the external clock, I don’t have enough knowledge to discuss it. My Mutec Ref 10 Nano simply makes the music sound much better, and I’ve done many A/B tests to verify this. But perhaps if it has no effect on the USB input on this device, it may have an effect on the Ethernet port.

Thanks for your help.

“Do you have PCM gain compensation in HQPlayer set to -6 dB as it should with Holo Audio?” = Yes.
When listening between the two options, I was careful to keep the sound level the same. Either way, even if I lowered the sound level further in PCM, it still sounded better!
An important point I forgot to mention: I set the Holo to PLL “OFF,” which is how everything finally works. Plus, it avoids any tuning delays between the two devices when changing frequencies between 44.1 and 48 (and multiple).
I know that measurements aren’t normally favorable for PCM, and especially without USB, but hey, my ears are telling me to keep this setting!
One piece in particular, Bach’s “Mass in B” by the Dunedin Consort, brought tears to my eyes and was a real pleasure to listen to in this PCM setup, but not in this way when listening to DSD.
In short, I’m confused by what the numerical measures should say and what I hear as a result!