Thanks for the loudness functionality. I’m enjoying more than I imagined during late evening listening.
2 Likes
Hi @jussi_laako,
This feature request is courtesy of an idea from @Rugby we discussed recently on his weekly video chats. He gave me permission to steal it so I am.
Something you often hear people say about digital filters is that their preference changes depending on the genre of music they are listening to. But very few people manually change filters when they change genres because it is a pain in the proverbial when you just want to listen to music.
Would it be possible for HQP to use file tags or genre information from Roon and enable users to define particular HQP output type/modulators/filters per genre ?
1 Like
HQPlayer specific file tags yes, you could write name of the filter to the specific tag. Changing modulators makes less sense, since it generally depends more on other things.
Genre metadata is not good for the purpose, because those genre strings are not well defined set, but instead there’s a huge amount of all kinds of genre strings in use.
This may already be possible, but I’ve not figured it out yet. How about a way to setup multiple configurations that can be pointed to by Roon. What I would like to do with this is have multiple DACs setup in HQPlayer with different configurations. Also, multiple different configurations for the same DAC.
Then in Roon point to a different HQPlayer target that would pull the corresponding configuration from HQPlayer. I realize you could only use one at a time. But this would be nice for changing DACs, changing DAC configurations for genre of music, and even AB comparing various HQPlayer configurations.
If this is already possible, please let me know!
Genres are a mixed bag, but Classical and Jazz are better defined than others. Having a default filter and then specifying others for Classical and Jazz would cover most use cases.
The other area where HQP might use file data to auto change filters is where an integer filter like closed form can’t be used because the DAC lacks a 48k DSD capability. Being able to autochange to a polysinc filter when the source format changes would be convenient.
This is possible from the HQPlayer main window, but not through the control API. Because control API doesn’t have access to managing the entire HQPlayer process.
1 Like
This is not a good idea, why wouldn’t you use the same filter for both families?
If you want to use certain filters for 48k sources, you really need to kick DAC manufacturer asses so that they fix their DACs to work correctly. Or use DACs that work correctly for 48k-base DSD sources too.
@andybob , prepare to open that can of whoop-ass !
Or just upgrade your Spring 1 to new Spring 3 !? 
1 Like
Only because certain filters, such as closed form, are unable mathematically to convert to 44.1k DSD if the source is 48k family. In that case I would prefer to swap to an alternative polysinc filter and keep a playlist or Roon Radio playing rather than experience silence.
Sure, I could get a DAC that handles 48k DSD properly, but there are a lot of DACs that don’t. I could also lobby manufacturers. But really all I want to do is listen to music.
1 Like
Just use some poly-sinc for the entire playlist and you don’t have that problem!
If I add such option, you have less motivation to lobby manufacturers and manufacturers have less motivation to fix their products… 
But it is also bad to do such operations due to hardware limitations that don’t really have reason to exist. Most of those DACs support 44.1k base for PCM and have clocks for it, for some reason someone has decided to add extra piece of code not to switch clocks and support DSD properly with 48k clocks… Usually it is also indication that the hardware manufacturer dislikes HQPlayer.
It would be a lot of work for me, and GUI pollution (extra things and complexity that shouldn’t exist), to work around firmware deficiency in a DAC. Correct place to fix it is at DAC side. HQPlayer has always been a no compromises design.
There have been similar feature requests for less powerful CPUs that would switch algorithms when CPU runs out of power. But these go to same category that should be fixed at the hardware side.
1 Like
For me, a client side feature that would be really helpful is a way to either change the output DAC directly or a way to import previously saved configurations. In general a little more control over the server settings. Right now I either have to VNC into my server or walk across my house to the server to change it, and when going between two different DACs on my desk it’s a little annoying. (Worth it for the quality sound, but still annoying.)
I don’t think this gets said enough on here: thanks for the excellent software! HQPlayer is something special and I don’t think it gets enough credit for that.
1 Like
On HQPlayer Desktop you can export/import settings through the File-menu and thus easily switch the settings.
Thanks @jussi_laako , this feature i’m aware of. the challenge is my server is on the other side of my house from my client where I listen. I have to walk across the house to make the DAC configuration change (or use a VNC connection). If I can make the changes directly from the client it will be a much better user experience.
thanks!
1 Like
Yes, I will now look more into it again, since Client ↔ Server connection now has authentication, encryption and such supported.
2 Likes
Hi @jussi_laako
ALAC is open source (since 2011?).
Can you please add support to HQP Desktop?
Yes I know I could convert everything to FLAC but it’s a lot and ALAC support would be nice ! 
What’s the technical reason you haven’t supported?
That includes the code to deal with the ALAC data, but not the code to deal with the .m4a container where it is typically housed.
I have a couple of additional requests for the volume control:
- When changing volume there are small click sounds between each 1db-step (I change from Roon which in turn change in HQPlayer). Its most noticeable if you change several steps at once.
- If possible (but I realize this is probably complicated), it would be nice if volume was free of DSP latency, maybe by adding an extra volume adjustment last in dsp, then remove that when the real volume is pushed through to the end of the pipeline.
Please check with HQPlayer’s volume control instead of Roon. In case Roon sends same value multiple times. But I have not noticed any clicks, the volume is ramped from one value to another using a very low distortion curve. (I don’t really use Roon) But if the ramp gets refreshed too frequently in the middle of ongoing ramp, you may get some side effects.
It is already as late as it can be. If you use a NAA, you will have some extra delay because of additional buffers. Do you have the “Short buffer” option enabled?
Yes, short buffer helps a little. The main reason for the latency for me is due to convolution file (384khz) with room correction. And I assume volume is before that, but it should be possible to add a temporary volume adjustment later and remove that when the real volume change comes through.
No, volume is last thing after all possible DSP.