Which HQP Filter are you using?

I have done extensive A/B with HQP (Sinc-M/NS9) vs MScaler - both going through a Hugo2 (and TT2). IMO, HQP has more bass definition and overall improved detail …but MScaler has a tad more depth delineation. The differences are subtle and perhaps more evident on some tracks than others - but they are present. I have beta testers of my SRC-DX product that concur. MScaler has an 11th order 301dB noise shaper and Rob Watts has indicated that this is what is needed for depth. I’ve had a dialog with Jussi about doing a similarly specified shaper.

Just wondering why you are using speaker settings at Roon side instead of HQPlayer?

I saw the setting choice in Roon, used it, and liked the result. Should it matter whether I use them in Roon or in HQP? I hadn’t given it much thought.

Now that Roon supports streaming 64-bit float to HQPlayer, it should matter only for DSD sources anymore.

1 Like

Is there any decrease in sound quality if using “Auto rate family”? If I don’t use that, I get a several minutes preprocessing step whenever the sample rate switches, and I have mixed stuff in my playlists.

I currently use poly-sinc-long-lp with NS9 shaper to up-sample to 172/192 and then over spdif to DAC.

@jussi_laako maybe cache the preprocerssing calculations to disk so it only needs to be done once/sample rate? Judging by the memory footprint it don’t look like to much data.

In fact one can expect better SQ using autorate family.
If your chosen filter supports it (not all of them do), it is the right choice.

1 Like

Why? I don’t agree with that…

Not really if you have a higher factor. At lower factors for example to 88.2/96 or 176.4/192 there is somewhat more difference. But it is not big.

What kind of filter on what computer? If you use something like poly-sinc-ext2 or poly-sinc-xtr, they initialize pretty fast. poly-sinc-long can indeed take a long time for non-integer ratio.

Problem is that there is almost infinite number of possible input and output rate combinations…

Yes, but you only need to cache the selected settings, so once the user has selected his preferences and performed the initial preprocessing, the cached data will be available from disk (can also be temporary cached in memory).

Here is what happened when I played my playlist (poly-sinc-long-lp without autorate family):

  • long delay
  • 44.1 played
  • another 44.1 played without delay
  • long delay
  • MQA (96khz) played
  • long delay
  • 44.1 played
    and so on

With caching to disk the long delays would only happen once/sample rate.

This set would need two cached, but the set is not bounded. You could have sources at 123 kHz, 31 kHz, 28 kHz, 507 kHz…

Yes, but eventually everything would be cached for the music you listen to. Not perfect, but better than always preprocess when switching sample rate.

That would be just too much. And on disk cache would be tricky to maintain as well.

There will be always setting combinations that are not practical for some reason, either because the initialization time grows too much, or because you cannot buy a computer fast enough to process it during playback. You just need to change the configuration to something that you consider tolerable and that can run on your hardware nicely. Maybe the initialization time for that case it not too bad on a 32-core Threadripper or similar.

I think you misunderstand me. In my case, mainly listening to Tidal, there would be maybe 2-3 caches (16/44.1 and I think 2 different for MQA). And they would only generate once when needed, with my current setting. So no unnecessary CPU or disk space used. If they get lost, no worries they will automatically be created when needed.

Basically, when a new sample rate starts to play in HQPlayer:

  • If cache exists for that sample rate with the current settings, load it
  • else generate and save for future use.

Still, it would probably not always be suited, for example on embedded on Raspberry. So an option to turn it on would be best.

That would be your case, but that is not a bounding condition.

That would be only necessary for very few corner cases, and many don’t want to wait that long even first time. I’d rather put constraint on the filter so that it refuses to do such conversion ratios. But the initialization time is massively less when going the other way, from 48k family to 44.1k family, like from 48k to 176.4k, totally non-issue. This is typically needed for DSD output cases.

Cache would also need version control, if the filter gets updated the cache needs to get updated, etc. Plus other management functionality. Sometimes you start playback and then find out the setting combination doesn’t run due to lack of CPU power - now you would have a lot of stale data cached that is never useful.

I just don’t think it’s worth the effort… And I try to avoid having too many obscure configuration options, there are already many

Just a suggestion. For me personally, HQPlayer would not be usable unless the auto-rate option was available, since I would spend more time waiting for preprocessing than listening to music.

And yes, you would need version handling, probably easiest to have a xml file with same base name with all needed information, and clear out all caches when upgrading HQPlayer.

Have been trying 3 filters: poly-sinc-ext2, poly-sinc-long-lp and sinc-M. My DAC is RME ADI-2 DAC, as preamp to NC500 power amps with op-amps and Volent VL-2 Paragon speakers.

Here are my impressions:

  • the most practical filter is without doubt the ext2, since it don’t need “Adaptive output rate” and has a fairly short latency. And it sounds good, but not quite as good as the others two.
  • the best sounding for me is sinc-M but its also has a horrible latency (over 10 seconds) and require “Adaptive output rate” to be enabled or it will do preprocessing at every switch of sample rate.
  • in between is the poly-sinc-long-lp which has a 3 second latency and sounds good but not quite as good as sinc-M for my ears. It also require “Adaptive output rate” to be enabled or it will do preprocessing at every switch of sample rate.

I have not tested poly-sinc-long-lp and sinc-M without “Adaptive output rate” since the several minute preprocessing that occur frequently on my playlists makes them to impractical to use.

Any other filter that comes close to these 3 for neutral sound quality?

I use poly-sinc-xtr-lp (up to DSD256 as my Fanless server is not powerfull enough to support DSD512).
I like Sinc-M as well, but on my gear I find the bass a little muddier ( although there is probably a bit deeper bass)

1 Like

Try poly-sinc-ext2

Already did, it was one of the three I tested. I think it lacked a tiny bit of clarity and details compared to the others. Also just tested the IIR filter which was kind of cool, sounded very laid back analogue.

But I am guessing the sound of the filters depends a lot of the DAC used, since they often (partially) replace the internal up-sampling in the DAC.

1 Like

If you implement a Clone() and an Equals() for your main settings class or struct, implementing memory caching up to a memory limit (configurable, 0 to disable) is trivial. No problems with versions and future settings, and for NUC users (who I would guess don’t restart very often) it would almost be the same. I have done something similar in a project I was working on.

Another idea: allow different settings for different input. For example, I might want to use the mqa filters for MQA input, but poly-sinc-long-lp for 44.1 and something else for DSD. Not easy to implement from a GUI standpoint, but it would add a nice functionality. It would also work well with memory caching.