HQ Player

[GMG]

Thanks @Miska

 

Can you explain what is the difference in the gain seen in the following log lines?

I use the larger of the 2 first gain numbers as a compensation for the convolution gain - in this case I used -12dB gain compensation,

But what is the 2nd set of gain numbers seen here for the actual filter?

And if I use the Matrix for the same impulse used here I get very different filter gain values in the log compared to here, as if the -12db gain I set is not used. Unless of course I am misreading the log

2022/01/08 21:03:20 Impulse response read from file /.hqplayer/filter_0-0.wav for channel 0 = 11.8178 dB
2022/01/08 21:03:20 Impulse response read from file /.hqplayer/filter_1-0.wav for channel 1 = 10.1872 dB
2022/01/08 21:03:20 Impulse response resampled with ratio: 0.229687
2022/01/08 21:03:20 Impulse response resampled with ratio: 0.229687
2022/01/08 21:03:20 Convolution filter of length 28503 initialized for channel 0 = 1.66734 dB (-0.435105 - 0.583098)
2022/01/08 21:03:20 Convolution filter of length 28503 initialized for channel 1 = -0.372368 dB (-0.313681 - 0.669102)

 

Same impulse but used through Matrix:

 

2022/01/08 20:58:42 Impulse response read from file /.hqplayer/impulse_B&W_0-0.wav (262144) = 11.8178 dB
  2022/01/08 20:58:42 	Initializing plugin "convolution" for sampling rate 44100
  2022/01/08 20:58:42 Impulse response read from file /.hqplayer/impulse_B&W_1-0.wav (262144) = 10.1872 dB
  2022/01/08 20:58:43 Impulse response "/.hqplayer/impulse_B&W_0-0.wav" resampled with ratio: 0.229687
  2022/01/08 20:58:43 Impulse response "/.hqplayer/impulse_B&W_1-0.wav" resampled with ratio: 0.229687
  2022/01/08 20:58:43 Convolution filter of length 61234 initialized  = 13.6673 dB (-1.73219 - 2.32135)
  2022/01/08 20:58:43 Convolution plugin initialized for 44100 using engine overlap-add
  2022/01/08 20:58:43 Convolution filter of length 61234 initialized  = 11.6487 dB (-1.24879 - 2.66374)

 

[Miska]

23 minutes ago, GMG said:

Can you explain what is the difference in the gain seen in the following log lines?

I use the larger of the 2 first gain numbers as a compensation for the convolution gain - in this case I used -12dB gain compensation,

But what is the 2nd set of gain numbers seen here for the actual filter?

 

There are two different ways to calculate gain. The one shown in the GUI is more reliable.

 

23 minutes ago, GMG said:

And if I use the Matrix for the same impulse used here I get very different filter gain values in the log compared to here, as if the -12db gain I set is not used. Unless of course I am misreading the log

 

Convolution engine and matrix are mutually exclusive. In Matrix you should use the mix gain setting for gain compensation. But it is not shown in the log same way, instead stated on the pipeline info output.

 

[GMG]

3 minutes ago, Miska said:

 

There are two different ways to calculate gain. The one shown in the GUI is more reliable.

 

 

Convolution engine and matrix are mutually exclusive. In Matrix you should use the mix gain setting for gain compensation. But it is not shown in the log same way, instead stated on the pipeline info output.

 

Thanks Miska, 

I am using Embedded, so there is no GUI for the gain calculation (only the plot which doesn't give the exact number)

 

When I used the Matrix for convolution I disabled the "convolution" tab and stated the gain compensation in the mix gain setting as you mention --> so I guess what I see in the log is as expected

[Miska]

5 minutes ago, GMG said:

I am using Embedded, so there is no GUI for the gain calculation (only the plot which doesn't give the exact number)

 

Ahh, yes, maybe this should be in the Embedded thread... 😅

 

Anyway, you can compare the plot and calculated values and see if there's some sensible looking match. But many times you already know from the filter design how much max gain it has.

 

5 minutes ago, GMG said:

When I used the Matrix for convolution I disabled the "convolution" tab and stated the gain compensation in the mix gain setting as you mention --> so I guess what I see in the log is as expected

 

Yes, then it is as it should.

 

[GMG]

Another thing about Matrix

I think there is a minor bug for Embedded - on one of my attempts to save a profile I accidently left the gain field totally empty. Not "0" or any other input. This caused an error that kept loading the configuration menu no matter what I tried.

The only way to overcome this was to manually edit HQPLayer.XML and fix the gain from "" to "0"  

[GMG]

4 minutes ago, Miska said:

Ahh, yes, maybe this should be in the Embedded thread... 😅

 

Oh no! 🤦‍♂️

I was not aware there was a separate thread for Embedded... There is so much info to keep up with in this thread and now you opened my eyes to yet another 😅

[LoryWiv]

3 hours ago, LoryWiv said:

8 hours ago, Miska said:

That's the point when new TLS connection is established with Qobuz or HRA server. This involves some random number generation and cryptographic work. What kind of backend are you using and what kind of hardware buffer settings? Here I'm already assuming that you don't have Short Buffer enabled.

 

Note that some older or different applications use older way to access Qobuz and may use non-encrypted connections for the streams.

 

Expand  

 ASIO backend Singxer SU-1 (SU-1 connects USB to my PC and I²S to my DAC), default buffer, short buffer unchecked. Singxer buffer setting highest (16384). Suggestions welcomed!

@Miskaamd @Hoshi - Update:  To asses the role of the Singxer DDC I switched to my FiiO BTR5 as USB DAC connected direct to PC --> still intermittent stutter near end of QoBuz streaming tracks but not every track. FiiO control panel buffer set to 2048.

[Miska]

44 minutes ago, GMG said:

Another thing about Matrix

I think there is a minor bug for Embedded - on one of my attempts to save a profile I accidently left the gain field totally empty. Not "0" or any other input. This caused an error that kept loading the configuration menu no matter what I tried.

The only way to overcome this was to manually edit HQPLayer.XML and fix the gain from "" to "0"  

 

I'll check this out for next release!

[Miska]

6 minutes ago, LoryWiv said:

@Miskaamd @Hoshi - Update:  To asses the role of the Singxer DDC I switched to my FiiO BTR5 as USB DAC connected direct to PC --> still intermittent stutter near end of QoBuz streaming tracks but not every track. FiiO control panel buffer set to 2048.

 

Is this like the Thesycon driver control panel? When you can set streaming mode to "Safe" and select biggest possible buffer? And leave "Buffer time" (for ASIO backend) in HQPlayer set to "Default" so that HQPlayer uses the values proposed by the driver.

 

[brother love]

@Miska,  Kiitos!  4.15.4 release has brought back my older i7-6700k performance to where it was before 4.15 releases only w/ all the extra goodies!  Hyperthreading restored, Psensor active as well as Activity Monitor all while playing ext3/ 7ECv2 DSD256 w/ zero dropouts. I can even stream Qobuz 192k/ 24 bit files to ext2/ 7ECv2 DSD256!  I continue to be marvelled by your wizardry. 😎

[Fleecyears]

16 hours ago, bogi said:

Use the greyed option with 4.15.4

 

If greyed or fully ticked, message appears on the bottom status line indicating if CUDA offload was used for convolution and/or the main processing.
You can try greyed option too, HQPlayer does some analysis to choose an option.

I have the following settings, which plays with greater consistency with minimal dropouts, but experience a horrible constant machine gun type stutter every 20 min or so, which can only be solved by stopping and starting again.

 

thoughts?

 

AMD Ryzen 3800X

RTX3060ti

64 Gb Ram

Ubuntu 20.10

NVIDIA 95.46 driver

[Miska]

8 minutes ago, Fleecyears said:

I have the following settings, which plays with greater consistency with minimal dropouts, but experience a horrible constant machine gun type stutter every 20 min or so, which can only be solved by stopping and starting again.

 

thoughts?

 

AMD Ryzen 3800X

RTX3060ti

64 Gb Ram

Ubuntu 20.10

NVIDIA 95.46 driver

 

Set "Multicore DSP" to grayed (auto).

 

[Fleecyears]

3 minutes ago, Miska said:

 

Set "Multicore DSP" to grayed (auto).

 

Thanks Miska. If I do that, the music keeps stuttering every 20-30 seconds or so and only 1-2 CPU cores are actually used. By having it Multicore Fully Ticked, I can see a large number of CPU cores are active 

[LoryWiv]

2 hours ago, Miska said:

 

Is this like the Thesycon driver control panel? When you can set streaming mode to "Safe" and select biggest possible buffer? And leave "Buffer time" (for ASIO backend) in HQPlayer set to "Default" so that HQPlayer uses the values proposed by the driver.

 

Interestingly @Miska, before I saw your reply I went back to the Singxer driver control panel and decreased buffer size to 1024, prefetch unchecked and no stutter 10 seconds before track end while streaming QoBuz albums. Checked prefetch and the problem did not recur!!! So paradoxically, using biggest buffer setting led to the problem and reducing buffer size solved it....does that make any sense to you. In any case I am happy with the result.

 

Update: Spoke to soon...problem IS less consistent w/reduced buffer, only occurs on some tracks but hnot fully resolved. Suggestions welcomed.

[Miska]

11 minutes ago, Fleecyears said:

Thanks Miska. If I do that, the music keeps stuttering every 20-30 seconds or so and only 1-2 CPU cores are actually used. By having it Multicore Fully Ticked, I can see a large number of CPU cores are active 

 

Are you using AMD optimized build of latest HQPlayer release? With Multicore DSP checked (force all enabled), you certainly have more cores loaded higher, but it likely won't work on current x64 CPUs.

 

[Miska]

12 minutes ago, LoryWiv said:

Interestingly @Miska, before I saw your reply I went back to the Singxer driver control panel and decreased buffer size to 1024, prefetch unchecked and no stutter 10 seconds before track end while streaming QoBuz albums. Checked prefetch and the problem did not recur!!! So paradoxically, using biggest buffer setting led to the problem and reducing buffer size solved it....does that make any sense to you. In any case I am happy with the result.

 

I don't know why that would work better, likely some driver's internal business. But good if it does!

 

Without prefetch there is no activity 10 seconds before end of the track, only at track switch time, but then there is possibility that the playback is not gapless.

 

[Fleecyears]

11 minutes ago, Miska said:

 

Are you using AMD optimized build of latest HQPlayer release? With Multicore DSP checked (force all enabled), you certainly have more cores loaded higher, but it likely won't work on current x64 CPUs.

 

 

Yes, I'm using HQPlayer 4.15.4 as obtained from your website with the title "Download for Ubuntu 20.04"

[Fleecyears]

27 minutes ago, Fleecyears said:

 

Yes, I'm using HQPlayer 4.15.4 as obtained from your website with the title "Download for Ubuntu 20.04"

 

Ok, I downloaded the following version from "Other Downloads" and ensured Multicore DSP is Greyed

hqplayer4desktop_4.15.4-66amd_amd64.deb    

Seems to be quite stable now;. No dropout thus far. Thank you Miska :-)

 

[Fleecyears]

5 hours ago, Fleecyears said:

 

Ok, I downloaded the following version from "Other Downloads" and ensured Multicore DSP is Greyed

hqplayer4desktop_4.15.4-66amd_amd64.deb    

Seems to be quite stable now;. No dropout thus far. Thank you Miska :-)

 

Quick update: Works perfectly with the Uptone EtherRegen appliance once plugged back in. I’m a happy camper. Thanks Miska !! 

[giordy60]

10 hours ago, Miska said:

 

Is this like the Thesycon driver control panel? When you can set streaming mode to "Safe" and select biggest possible buffer? And leave "Buffer time" (for ASIO backend) in HQPlayer set to "Default" so that HQPlayer uses the values proposed by the driver.

 

Jussi,
when I use your image for NAA - fitlet (4123 x64)
  do I set the buffer time to 100ms?
using qobuz do I set it to a higher value?
thank you.

[MasterWarzombie]

How to know which time value of the buffer is to be applied in its configuration. On default, I have "little crackles" listening. If I set the value to 10ms. No problem .
For safety's sake, I would like to set a higher value (100 ms)

I have a Qutest DAC and a Sotm streamer

[stefano_mbp]

19 minutes ago, MasterWarzombie said:

and a Sotm streamer

Running HQPlayer OS (Embedded) …

I have a SOtM sMS200 (Neo not Ultra) and in my setup little crackles were there too.

It seems a SOtM little issue as using RoPieeeXL/NAA crackles are not there.

I solved the issue setting Buffer Time to 20ms.

As you experienced 10ms are enough but to stay safe I doubled …

I tried with 100ms but crackles came back. 

[Miska]

5 hours ago, giordy60 said:

when I use your image for NAA - fitlet (4123 x64)
  do I set the buffer time to 100ms?
using qobuz do I set it to a higher value?

 

When using NAA it is best leave it "Default". Or set it to 100 ms.

 

[Miska]

3 hours ago, MasterWarzombie said:

How to know which time value of the buffer is to be applied in its configuration. On default, I have "little crackles" listening. If I set the value to 10ms. No problem .
For safety's sake, I would like to set a higher value (100 ms)

I have a Qutest DAC and a Sotm streamer

 

Default value is about 100 ms. But if lower values make it work better for you, you can use those instead.

 

I suspect this could be also related to 802.3x Flow Control issues, if the flow control doesn't become active causing packet losses.

 

[Kalpesh]

do you confirm poly-sinc-gauss-long for classical music, Digital recording from -79, not digitized ? 

 

I use my Holo DSD256 with ASDM7ECv2 99.9 % of the time ; do I understand correctly that in your opinion the 0.1% has no technical justification even with digital recordings made prior to the SDM era or digitized with Pacific Microsonic ?