HQPlayer Linux Desktop and HQplayer embedded

[audiofool]

2 hours ago, Miska said:

 

That would be really strange with a DAC chip that supports DSD... From the hardware architecture perspective I don't see a reason why they wouldn't run the chip in DSD Direct mode.

 

 

Why not LNS15 at 32 bits?

 

They replied saying DSD is converted to PCM internally so that DSD's volume can be adjusted.  Really strange since they show this diagram.  Very slight clicks at end of dsd songs in sdm mode, no clicks in pcm mode.  512sdm has the same gain as 256sdm but needs to be power cycled to switch back to pcm so something is different with 512 sdm mode in the dac. 

 

I was looking at this for linearity, maybe it doesn't mean anything and AKM is best at 32 bits?

[Miska]

2 hours ago, audiofool said:

They replied saying DSD is converted to PCM internally so that DSD's volume can be adjusted.  Really strange since they show this diagram.  Very slight clicks at end of dsd songs in sdm mode, no clicks in pcm mode.  512sdm has the same gain as 256sdm but needs to be power cycled to switch back to pcm so something is different with 512 sdm mode in the dac. 

 

Sounds strange indeed. Maybe best to run it at 705.6/768k PCM.

 

2 hours ago, audiofool said:

I was looking at this for linearity, maybe it doesn't mean anything and AKM is best at 32 bits?

 

It is fairly linear until -90 dB or -100 dB where it begins to go off (15 or 17 bits). But since it goes through modulator in the DSP section, it may not necessarily get better. You could try LNS15 with 15, 17 and "Default" settings if you notice difference one way or the other, especially in quiet tails / fade outs.

 

For example EVGA NU Audio card behaves nicely with -120 dB test tone using 32-bit input.

 

[audiofool]

6 hours ago, Miska said:

 

Sounds strange indeed. Maybe best to run it at 705.6/768k PCM.

 

 

It is fairly linear until -90 dB or -100 dB where it begins to go off (15 or 17 bits). But since it goes through modulator in the DSP section, it may not necessarily get better. You could try LNS15 with 15, 17 and "Default" settings if you notice difference one way or the other, especially in quiet tails / fade outs.

 

For example EVGA NU Audio card behaves nicely with -120 dB test tone using 32-bit input.

 

The EVGA is on my radar for when I build a new PC.  Since the below results for the EVGA were similar to the FiiO results I used your EVGA measurements as a starting point for the FiiO linearity. 

 

So, I created a 192khz 32-bit float 1khz sine wave at -110db in Audacity.  HQPlayer set to pcm and 0 gain with LNS dither and volume on the dac set to maximum.  Can just hear the tone above a very low noise floor.  I was looking for the lowest noise with the cleanest tone.  18 or 19 bits seemed the best, anything higher including 32 bit seemed to make the noise floor not as clean.  smd output mode was clean but the noise floor was higher than pcm, so a no go.  Is this a valid alternative to listening to fade outs to determine dither settings?

 

Thanks Miska

 

 

 

[Miska]

8 hours ago, audiofool said:

So, I created a 192khz 32-bit float 1khz sine wave at -110db in Audacity.  HQPlayer set to pcm and 0 gain with LNS dither and volume on the dac set to maximum.  Can just hear the tone above a very low noise floor.  I was looking for the lowest noise with the cleanest tone.  18 or 19 bits seemed the best, anything higher including 32 bit seemed to make the noise floor not as clean.  smd output mode was clean but the noise floor was higher than pcm, so a no go.  Is this a valid alternative to listening to fade outs to determine dither settings?

 

OK, sounds like the chip is indeed not in bypass mode, because NU Audio has same analog noise floor for PCM and DSD (limited by the analog parts, not by the D/A conversion). Although in bypass mode the 3.5 dB output level difference makes also 3.5 dB difference in the noise floor level, when that is compensated for by dropping PCM input level by 3.5 dB, the noise floors are same. (reason for this level difference is that DSD specs allow short term peaks reach +3.15 dB level and thus AKM has decided to keep headroom for that, unlike ESS)

 

Yes, that is one way to determine suitable setting. You can also test with music, using some very quiet passage, or fade-out. Using same method you can try reducing the word length step by step until you can hear the noise floor starting to come up. This is the point where digital noise floor crosses the analog one. With 705.6/768k rates and LNS15, you can probably go to 15 or 16 bits and the digital noise floor still stays below analog one (due to noise shaping).

 

From your description sounds like the linearity error comes from actual processing precision of the on-chip DSP.

 

[Bayan]

On 7/7/2020 at 2:20 AM, Miska said:

 

It likely stops with an error, you could check the log file if there are some errors. Amount of RAM doesn't matter here, HQPlayer Embedded doesn't use a lot of memory.

 

I figured out exactly what scenarios it fails in. sinc-L works only when upsampling, not when downsampling. sinc-S on the other hand works when upsampling and downsampling.

 

My DAC supports maximum 192khz inputs, when I'm playing a 352khz or 384khz file sinc-S can play it but sinc-L fails. Here's the log file when using sinc-L with a higher bitrate file that needs to be downsampled before being sent to the DAC:

 

  2020/07/12 21:29:56 Set volume: -3
& 2020/07/12 21:31:48 Playlist clear
& 2020/07/12 21:31:48 Playlist add URI: http://127.0.0.1:9102/da9cad7cd273410aadc1b9b7bcf7bbae/stream.raw
& 2020/07/12 21:31:48 Play
  2020/07/12 21:31:48 Offload: resampler=disabled convolution=disabled
+ 2020/07/12 21:31:48 Playback engine running
  2020/07/12 21:31:48 No suitable output rate for 352800, stop
  2020/07/12 21:31:48 Stop request (tail)
& 2020/07/12 21:31:48 Stop...
  2020/07/12 21:31:48 Teams: 1
  2020/07/12 21:31:48 Places: 1
  2020/07/12 21:31:48 Parallel threads: 8
  2020/07/12 21:31:48 Nested parallelism: 4
  2020/07/12 21:31:48 Parallel pipelines: 4
- 2020/07/12 21:31:48 Playback engine stopped
& 2020/07/12 21:31:48 ...stopped
  2020/07/12 21:31:48 Set volume: -3
  
  Is this something that can be patched/fixed @Miska?

 

 

[Miska]

1 hour ago, Bayan said:

I figured out exactly what scenarios it fails in. sinc-L works only when upsampling, not when downsampling. sinc-S on the other hand works when upsampling and downsampling.

 

My DAC supports maximum 192khz inputs, when I'm playing a 352khz or 384khz file sinc-S can play it but sinc-L fails. Here's the log file when using sinc-L with a higher bitrate file that needs to be downsampled before being sent to the DAC:

 

Ahh, yes, that is on purpose due to sinc-L's lower stop-band attenuation, it is not very suitable for decimation.

 

[Bayan]

3 minutes ago, Miska said:

 

Ahh, yes, that is on purpose due to sinc-L's lower stop-band attenuation, it is not very suitable for decimation.

 

 

Is it bad for power-of-two decimation as well?

 

Is there a way to configure to use sinc-L but have it automatically use another algorithm when needing to do decimation? (whatever the best decimation algorithm is - I'm always doing power of 2 decimation). Otherwise, changing to a different thing by hand when using 352/384 sources/files and then changing back is not really usable.

[Miska]

16 minutes ago, Bayan said:

Is it bad for power-of-two decimation as well?

 

Yes...

 

17 minutes ago, Bayan said:

Is there a way to configure to use sinc-L but have it automatically use another algorithm when needing to do decimation?

 

No, only option is to have different filters for 1x and higher source rates.

 

[Bayan]

1 hour ago, Miska said:

 

Yes...

 

 

No, only option is to have different filters for 1x and higher source rates.

 

Makes sense. Here are two feature requests:

 

1) to choose conversion algorithm & dithering based on source format (structured like the Room sample rate conversion page)

2) to allow for convolution matrix selection by source format (so we can use 192khz filter for 192khz playback and 176khz filter for 176khz playback).

 

[Miska]

5 hours ago, Bayan said:

1) to choose conversion algorithm & dithering based on source format (structured like the Room sample rate conversion page)

 

HQPlayer is not limited to such source formats. You can also have 123 kHz and 148 kHz source files and such. In fact I'm encouraging producers to choose optimal sample rate based on frequency content of their recordings instead of only few choices. This means that there is not practically bounded set of source formats.

 

For example for 2L recordings, optimal delivery format would be 120 kHz 18-bit FLAC. I have also tested this and it works well and makes the resulting files notably smaller than MQA version while not removing any content unlike MQA.

 

5 hours ago, Bayan said:

2) to allow for convolution matrix selection by source format (so we can use 192khz filter for 192khz playback and 176khz filter for 176khz playback).

 

Similar case to the above one. In addition this is totally unnecessary, I recommend providing convolution filters at 352.8 or 384 kHz rate. HQPlayer will scale the filters to match the source rate. Convolution is performed always at the source rate, except for DSD-to-PCM conversion case where it is performed as PCM for 1/16th of the DSD source rate.

 

[craighartley]

12 minutes ago, Miska said:

 

HQPlayer is not limited to such source formats. You can also have 123 kHz and 148 kHz source files and such. In fact I'm encouraging producers to choose optimal sample rate based on frequency content of their recordings instead of only few choices. This means that there is not practically bounded set of source formats.

For example for 2L recordings, optimal delivery format would be 120 kHz 18-bit FLAC. I have also tested this and it works well and makes the resulting files notably smaller than MQA version while not removing any content unlike

 

I see your point, but I don’t see why this would preclude providing set options for  ‘such source formats’, by which you mean those used in (almost?) all cases by your many customers. 

[Bayan]

20 minutes ago, Miska said:

 

HQPlayer is not limited to such source formats. You can also have 123 kHz and 148 kHz source files and such. In fact I'm encouraging producers to choose optimal sample rate based on frequency content of their recordings instead of only few choices. This means that there is not practically bounded set of source formats.

 

For example for 2L recordings, optimal delivery format would be 120 kHz 18-bit FLAC. I have also tested this and it works well and makes the resulting files notably smaller than MQA version while not removing any content unlike MQA.

 

 

Similar case to the above one. In addition this is totally unnecessary, I recommend providing convolution filters at 352.8 or 384 kHz rate. HQPlayer will scale the filters to match the source rate. Convolution is performed always at the source rate, except for DSD-to-PCM conversion case where it is performed as PCM for 1/16th of the DSD source rate.

 

Then perhaps have a Matrix format where one of the fields you can enter is the source format. With a set of defaults. That way, for the common formats It's easy to set what algorithm you want

[Miska]

7 minutes ago, craighartley said:

I see your point, but I don’t see why this would preclude providing set options for  ‘such source formats’, by which you mean those used in (almost?) all cases by your many customers. 

 

There are already too many settings and there is no point in adding such thing for just some obscure corner cases.

 

5 minutes ago, Bayan said:

Then perhaps have a Matrix format where one of the fields you can enter is the source format. With a set of defaults. That way, for the common formats It's easy to set what algorithm you want

 

When data reaches pipeline matrix, there is no information about the source format anymore...

 

[Bayan]

1 minute ago, Miska said:

 

There are already too many settings and there is no point in adding such thing for just some obscure corner cases.

 

 

When data reaches pipeline matrix, there is no information about the source format anymore...

 

It's not very obscure - A lot of people have files that are higher resolution than their dacs & many people on here seem to love sinc-L (including me). I understand if it's not a priority for you though

[Miska]

9 minutes ago, Bayan said:

It's not very obscure - A lot of people have files that are higher resolution than their dacs & many people on here seem to love sinc-L (including me). I understand if it's not a priority for you though

 

You cover 99% of the cases by setting sinc-L filter for 1x rates and something else like poly-sinc-xtr, poly-sinc-ext2 or sinc-S for Nx rates.

 

Changing filter with HQPlayer Client at the same time when you load some higher than DAC resolution album for playback and star the playback takes couple of seconds.

 

Compared to that, adding such configuration option for cases where some unsuitable filter is preferred for hires and file resolution is higher than what DAC supports is pretty rare. Many already complain that there are already too many configuration options, so I try to keep the configuration complexity reasonably low. It also makes a lot of difference for how complex release testing gets and how many bugs there can be due to possible configuration combinations.

 

[craighartley]

24 minutes ago, Miska said:

 

You cover 99% of the cases by setting sinc-L filter for 1x rates and something else like poly-sinc-xtr, poly-sinc-ext2 or sinc-S for Nx rates.

 

C

44 minutes ago, Miska said:

 

There are already too many settings and there is no point in adding such thing for just some obscure corner cases.

 

 

When data reaches pipeline matrix, there is no information about the source format anymore...

 

hanging filter with HQPlayer Client at the same time when you load some higher than DAC resolution album for playback and star the playback takes couple of seconds.

 

Compared to that, adding such configuration option for cases where some unsuitable filter is preferred for hires and file resolution is higher than what DAC supports is pretty rare. Many already complain that there are already too many configuration options, so I try to keep the configuration complexity reasonably low. It also makes a lot of difference for how complex release testing gets and how many bugs there can be due to possible configuration combinations.

 

 

[craighartley]

45 minutes ago, Miska said:

 

There are already too many settings and there is no point in adding such thing for just some obscure corner cases.

 

 

 

 

With respect, it seems strange not to see the wider application of this. I’m not thinking of decimation. It’s hardly an obscure case, for example, that people have processors that allow only some source rates to be used with a complex filter. Your introduction of the separate options for 1x and nx did indeed make a huge difference in usability, because although it made setup slightly more complicated in setup, it made it more flexible in use. But it’s still limiting for those of us with a range of high resolution rate files. 
 

Personally - and yes you may see this as an ‘obscure corner case’ - I’d love it to go even further and enable me to send DSD256 source files direct to my T&A DAC8 DSD but upsample lower resolution DSD files to 256. You might say this would be more complex in setup, but it would make it much less complex in use than fiddling around with settings between albums.

[Miska]

3 minutes ago, craighartley said:

Personally - and yes you may see this as an ‘obscure corner case’ - I’d love it to go even further and enable me to send DSD256 source files direct to my T&A DAC8 DSD but upsample lower resolution DSD files to 256. You might say this would be more complex in setup, but it would make it much less complex in use than fiddling around with settings between albums.

 

That is also something that makes things complex. Because without Direct SDM you have all the DSP options like volume control, convolution, cross-feed and such, that you could still want to have for DSD256 -> DSD256 case as well.

 

And one thing I  don't want to do is to flip between something that has volume control and something that doesn't have volume control on the fly because it is potentially dangerous.

 

[craighartley]

2 hours ago, Miska said:

 

That is also something that makes things complex. Because without Direct SDM you have all the DSP options like volume control, convolution, cross-feed and such, that you could still want to have for DSD256 -> DSD256 case as well.

 

And one thing I  don't want to do is to flip between something that has volume control and something that doesn't have volume control on the fly because it is potentially dangerous.

 

Thanks. Of course I hadn’t thought it through properly with volume control etc. I wouldn’t want that danger either!
 

I still think the point about choice of filters stands. 

[Miska]

For that reason the filter switching in Client is very easy, almost as easy as it was in Desktop v3. Of course only challenge is mixed-rate playlists, but even then, HQPlayer playback just stops when incompatible filter is encountered and then it is relatively quick to switch filter and restart playback.

 

[craighartley]

35 minutes ago, Miska said:

For that reason the filter switching in Client is very easy, almost as easy as it was in Desktop v3. Of course only challenge is mixed-rate playlists, but even then, HQPlayer playback just stops when incompatible filter is encountered and then it is relatively quick to switch filter and restart playback.

 

Yes. But I don’t often use Client as I am using Roon as a front end in my listening room, controlled from an iPad (I don’t think this sort of setup is unusual), so automation of filter choice in setup depending on source file is invaluable. That’s why the provision of different filter settings for 1x and nx was a joy. 
 

Automation of choice of filter depending on whether source material needed an apodising filter or not (as you discussed with others somewhere above) would be fantastic. 

 

 

[Miska]

4 minutes ago, craighartley said:

Yes. But I don’t often use Client as I am using Roon as a front end in my listening room, controlled from an iPad (I don’t think this sort of setup is unusual), so automation of filter choice in setup depending on source file is invaluable. That’s why the provision of different filter settings for 1x and nx was a joy. 

 

Then the correct place to have the filter switching would be in Roon...

 

5 minutes ago, craighartley said:

Automation of choice of filter depending on whether source material needed an apodising filter or not (as you discussed with others somewhere above) would be fantastic.

 

That won't be automatic either, but indication during playback that apodizing filter would be useful. I'm not planning to do pre-analysis of the content at this point since it is time consuming and doesn't work for Roon use cases anyway either. So during playback you would get indication that apodizing filter would be useful.

 

For HQPlayer's library it would be theoretically doable, but would increase library scan times significantly.

 

[craighartley]

58 minutes ago, Miska said:

 

Then the correct place to have the filter switching would be in Roon...

 

 

That won't be automatic either, but indication during playback that apodizing filter would be useful. I'm not planning to do pre-analysis of the content at this point since it is time consuming and doesn't work for Roon use cases anyway either. So during playback you would get indication that apodizing filter would be useful.

 

For HQPlayer's library it would be theoretically doable, but would increase library scan times significantly.

 

Indication visible in Roon or just via Client?

[Miska]

1 hour ago, craighartley said:

Indication visible in Roon or just via Client?

 

Unless Roon adds support for it, only in HQPlayer server and Client.

 

There are lot of things Roon could do through the control API, but doesn't. However, I don't have control over that.

 

[Outlaw]

Trying Hqplayer embedded.I can get it to work with Roon but it is not recognized by mconnect player hd ?