HQ Player

[chipvn]

@Miska I am also another stubborn boy on passive cooling server or NAA. It is not just about arguable debate on acoustic noise or electronic noise. The main reason for me to stay on passive cooling is humidity and dust. My listening room is a non air-conditioning room in a very high humidity hot country. My active cooling Synology NAS got tons of dust and component corrosion issue with just 2 small fans set at quiet frofile (very low speed and low acoustic noise) even though I keep open to clean up regularly.

Keep blowing "fresh but dusty air at about 95% (or even 98%) humidity into a case is not a good option at all here. 😅

[Miska]

7 hours ago, Jud said:

Pretty much any DAC? Especially those with more large discrete parts? Any notion what the tradeoff might be between heat cycling (warming up when turning on then cooling down when turned off) and constant warm temperature (always on)?

 

Not all DACs run notably warm, so it doesn't apply to all devices.

 

Heat cycling shouldn't be an issue especially for typical home use. At least I don't remember it ever being considered an issue in the electronics engineering circles I've been dealing with. Biggest stress happens when board is used for SMD part cooling and there the stress is on the board if the components produce notable amount of heat, but already basic good quality FR4 can withstand a lot of such. Schiit seems to be particularly into this kind of design, to the extent some of their boards make sound when heating up (Jotunheim). No problems for me so far, and since it warms up quite a lot, I turn it off when I'm not using it.

 

I've just seen so many broken electrolytic capacitors over my career, that it is my main concern regarding electronics life span. Common refurbishing of old hifi gear is to "re-cap" the equipment.

 

Temperature changes is much more stressful for automotive use where ambient temperatures can vary from -40C to +50C.

 

You can find a lot of information about the capacitor stuff on the 'net, for example here:

https://resources.altium.com/p/electrolytic-capacitor-lifespan

 

[Miska]

2 hours ago, chipvn said:

Keep blowing "fresh but dusty air at about 95% (or even 98%) humidity into a case is not a good option at all here. 😅

 

I can imagine. At summer time, humidity here is around 50-65%. Now at winter it is around 25% or lower inside.

 

Dust of course still exists and with a bit of static electricity in dry conditions it attaches on surfaces. But the cases I'm using have dust filters for all air intakes that actually work pretty well. So I just weekly vacuum the dust filters. And once a year blow the machine interiors with compressed air.

 

[AudioDoctor]

If we're on the topic of humidity and dust in our music PCs and NAS devices...

 

I have one of these in my listening area.

 

https://www.blueair.com/us/Master-2518.html?dwvar_Master-2518_blueair_configuration=40i

 

Initially it was to keep dust off my vinyl records, but it of course also helps to keep dust out of the HQP pc and stereo equipment just as well. Humidity isn't an issue for me, even in winter as I have a system in my HVAC that keeps the humidity constant.

[Miska]

6 hours ago, Reg19 said:

Generally, I keep the volume level on the preamp relatively high and control the music volume level using the HQPlayer volume (through Roon). Currently, I have adjusted the preamp volume level so that at ideal listening level, the HQPlayer volume is at -35dB.

 

The question is: ideally, at what volume level should I keep HQPlayer at (I can adjust my preamp volume so that my normal listening level is at that HQP volume level)?

 

This is pretty much optimal approach.

 

To find optimal settings:

1. Find some material that is not very loud, some softest material you have.
2. Turn down pre-amp volume and set HQPlayer volume to -3 dBFS.
3. Start playback.
4. Turn pre-amp volume to highest setting you would ever want to listen this material.
5. Adjust HQPlayer volume to wanted listening level

Point is that the pre-amp volume sets the maximum level and then HQPlayer volume is used to do the actual adjustment. This minimizes thermal noise from the analog stages while keeping maximum volume safely limited.

 

[Reg19]

4 hours ago, Miska said:

 

This is pretty much optimal approach.

 

To find optimal settings:

1. Find some material that is not very loud, some softest material you have.
2. Turn down pre-amp volume and set HQPlayer volume to -3 dBFS.
3. Start playback.
4. Turn pre-amp volume to highest setting you would ever want to listen this material.
5. Adjust HQPlayer volume to wanted listening level

Point is that the pre-amp volume sets the maximum level and then HQPlayer volume is used to do the actual adjustment. This minimizes thermal noise from the analog stages while keeping maximum volume safely limited.

 

Thanks @Miska. This helps.

 

My question also pertained to the following: is there a level beyond which digitally attenuating signal using HQP volume control becomes detrimental?

[GUTB]

Anyone try out DSD1024? Does HQPlayer support it?

[StreamFidelity]

12 minutes ago, GUTB said:

Anyone try out DSD1024? Does HQPlayer support it?

No problem 

 

[Chodi]

A simple question for our host. When the apodizing counter goes nuts raising into the hundreds or past a thousand on particular albums is this actually an apodizing issue or a miss-reading of the software (HQP)? I have it happen rarely but as recently as yesterday with a classical album that I was playing from hard disk. Is this a false reading or is the specific recording really loaded with high frequency problems? I was first using a non apodizing filter then switched to apodizing. The counter still was constatly raising.

[Account Closed]

1 hour ago, Chodi said:

A simple question for our host. When the apodizing counter goes nuts raising into the hundreds or past a thousand on particular albums is this actually an apodizing issue or a miss-reading of the software (HQP)? I have it happen rarely but as recently as yesterday with a classical album that I was playing from hard disk. Is this a false reading or is the specific recording really loaded with high frequency problems? I was first using a non apodizing filter then switched to apodizing. The counter still was constatly raising.

The apodizing counter is pre-filter so will not change with a filter change. If you have a high count use a apodizing filter and it will take care of the problem but the count will not change as it is monitored before the filter not after.

[eboy]

@MiskaShould I be concerned about CPU bottleneck when using i7-7700k with RTX 2080 ti running CUDA offload in Hqplayer?

[Miska]

20 hours ago, Reg19 said:

My question also pertained to the following: is there a level beyond which digitally attenuating signal using HQP volume control becomes detrimental?

 

The limit is imposed by analog domain. So the main task is to minimize impact of analog signal path. Looking from another perspective it is about optimizing attenuation before final power amp gain, so that there is not too much back and forth attenuation + gain which means SNR loss.

 

For example if pre-amp (pre-att) gain is -40 dB and power amp gain is 36 dB, then the effective gain is 4 dB. And 36 dB is "loss". First attenuating something a lot before amplifying it again a lot.

 

In my case, for loudspeaker systems, I find the used volume range is within about 26 dB. Thus in optimal case, maximum result would have -3 dBFS in digital and 0 dBr in analog pre-amp (IOW, no pre-amp) and then lowest HQPlayer volume setting would be -29 dB. In practice, this may not be achievable if the power amp doesn't have exactly perfect gain setting. But the point is to optimize this whole thing as one to get reasonably close to the optimum.

 

[Miska]

9 hours ago, eboy said:

@MiskaShould I be concerned about CPU bottleneck when using i7-7700k with RTX 2080 ti running CUDA offload in Hqplayer?

 

Are you experiencing some specific bottleneck? Sounds like this combination should perform pretty well for many setting combinations. Although two or three more cores wouldn't hurt. Are you experiencing CPU being close to the max?

 

[Hensema]

My Holo Spring 3 is locking very slowly on spdif. The first lock takes 20 seconds. Because of that I miss 20 seconds of music. Is it possible to have an option for hqplayer to always send a signal regardless if there is music or not?

[Miska]

5 hours ago, Hensema said:

My Holo Spring 3 is locking very slowly on spdif. The first lock takes 20 seconds. Because of that I miss 20 seconds of music. Is it possible to have an option for hqplayer to always send a signal regardless if there is music or not?

 

Why are you using S/PDIF with HQPlayer + Spring 3 instead of USB!? That will impose some serious limitations.

 

[Mahler and Bach on Computer]

 

I have been using HQPlayerDesktop since March 2020.  I have a dedicated private network for the music playing, for the sake of sound as well as network security.  The key elements which are relevant to this discussion I think are, a Router from ASUS RXAU82, Mac Mini M1, and SotM sMS 200 as NAA.  Everything worked great until the HQPlayerDesktop Version 16.2.  From version 16.1 to 16.2, there was a huge difference in performance.  Starting at 16.2, HQP continuously run into the issue of stuttering.  I was told that I needed to connect my computer and NAA to an external network, so the version of HQPlayerDesk can be validated/verified.  I connected my computer to a network mesh point manufactured by eero to with local Comcast Service.  Unfortunately it did not resolved the issue.  It worths noting, that when I connected the computer to eero mesh point, instead of ASUS router, with version 16.1, everything works fine as well.  

 

Since I ran into the trouble with version 16.2 and beyond, I stopped following this thread because I barely could try anything new discussed in this thread.  I tried newer versions of HQPlayer Desktop, from time to time, hoping one of them would resolve the issue ultimately.  With, 17.1, 18.1, and 19.1, there was no luck.  Given 20.1 coming out, I started worrying that with Mac OS keep upgrading, ultimately version 16.1 will not compatible by the newer version of OS.  

 

So I posted the note here asking for help to resolve this difficulty.  

 

Thank you very much!

 

 

 

 

[Miska]

3 hours ago, Mahler and Bach on Computer said:

I have been using HQPlayerDesktop since March 2020.  I have a dedicated private network for the music playing, for the sake of sound as well as network security.  The key elements which are relevant to this discussion I think are, a Router from ASUS RXAU82, Mac Mini M1, and SotM sMS 200 as NAA.  Everything worked great until the HQPlayerDesktop Version 16.2.  From version 16.1 to 16.2, there was a huge difference in performance.  Starting at 16.2, HQP continuously run into the issue of stuttering.  I was told that I needed to connect my computer and NAA to an external network, so the version of HQPlayerDesk can be validated/verified.  I connected my computer to a network mesh point manufactured by eero to with local Comcast Service.  Unfortunately it did not resolved the issue.  It worths noting, that when I connected the computer to eero mesh point, instead of ASUS router, with version 16.1, everything works fine as well.  

 

Since I ran into the trouble with version 16.2 and beyond, I stopped following this thread because I barely could try anything new discussed in this thread.  I tried newer versions of HQPlayer Desktop, from time to time, hoping one of them would resolve the issue ultimately.  With, 17.1, 18.1, and 19.1, there was no luck.  Given 20.1 coming out, I started worrying that with Mac OS keep upgrading, ultimately version 16.1 will not compatible by the newer version of OS.  

 

So I posted the note here asking for help to resolve this difficulty.  

 

Stuttering is not related to having internet access or not. You will need internet access, but that's a different story.

 

First question is what kind of settings are you using? For example the "Multicore DSP" setting has been changing over time. Generally on Mac Mini M1 you should have this set to grayed (auto).

 

So first try RedBook and normal hires PCM with current default settings:

1x filter = poly-sinc-gauss-long

Nx filter = poly-sinc-gauss-hires-lp

Modulator = ASDM7ECv2

Multicore DSP = grayed

 

This overall should work. If it doesn't, then the problem is more likely in the network/NAA combination. You can check this by connecting your DAC directly to the Mac.

 

If there's stuttering/drop-outs with NAA connection, first thing to check is whether 802.3x Flow Control is supported and active. However, this is not related to HQPlayer version, so it is unlikely this being an issue.

 

My first suspect is wrong setting for "Multicore DSP".

 

(Mac Mini M1 is sort of easy case, because I have one and there are only two notable variants, 8 GB and 16 GB RAM models)

[Mahler and Bach on Computer]

 

Hi, Jussi.  Thank you for your suggestion. I made some progress.  It turned out that the issue is relate to the DSD decoding, with newer version of HQPlayer.  Upon your suggestion, I started with PCM, even from DSD source material.  The stutter immediately stopped, with both USB from Mac M1 to DAC directly, or USB to SotM sMS 200 to DAC.  I did this by selecting default output mode to be PCM. However, the moment I chose default output mode to be SDM, the stutter came back, no matter how low the settings I chose for the PCM based material to do DSD upsampling or if I played a DSD source.  All these observations/behaviors were repeated for both versions 16.2 and 19.1.

 

Does that mean I can only do PCM from now on if I move beyond version 16.2?  Here are extra  little bit details of DSD decoding for the system.  After NAA (SotM), a USB output is fed into Mutec USB 3+, which does the reclocking as well as DSD decoding up to 256K.  It should be noted that with version of 16.1, the DSD output worked well with the equipment mentioned here, namely NAA, Mutec USB 3+, which is followed by DAC from Metrum or Sonnet through AES/EBU.  So my speculation is that between versions 16.1 to 16.2, the SDM as Default Output setting may have some major changes as well?

 

Multicore DSP setting has been always grayed, from day one almost three years ago.  The computer is Mac M1 with 16GB ram.

 

My further question is, if I continue using version 16.1, do you expect this version likely will be supported by new OS system for the many years to come?

 

Thank you again.  

 

 

 

[Miska]

It is not clear what are you exactly trying to do? What are your exact settings?

 

2 hours ago, Mahler and Bach on Computer said:

USB output is fed into Mutec USB 3+, which does the reclocking as well as DSD decoding up to 256K.  It should be noted that with version of 16.1, the DSD output worked well with the equipment mentioned here, namely NAA, Mutec USB 3+, which is followed by DAC from Metrum or Sonnet through AES/EBU.

 

As first thing I would take either HQPlayer or Mutec out of the picture. Just choose which of the DSP you want to use. But don't combine these two.

 

[Miska]

2 hours ago, Mahler and Bach on Computer said:

My further question is, if I continue using version 16.1, do you expect this version likely will be supported by new OS system for the many years to come?

 

I don't know. Only time will tell. You will have some quality limitations though.

 

[Fredc]

3 hours ago, Miska said:

 

I don't know. Only time will tell. You will have some quality limitations though.

 

Depending on your hardware configuration, the newer versions may place higher load on the CPU which can cause stuttering. I find I can't run certain filters in 20.2 and am now reverting back to 19.3. 

[eboy]

On 12/17/2022 at 5:14 AM, Miska said:

 

Are you experiencing some specific bottleneck? Sounds like this combination should perform pretty well for many setting combinations. Although two or three more cores wouldn't hurt. Are you experiencing CPU being close to the max?

 

No cpu bottleneck using i7 7700k and rtx 2080 ti

[Mahler and Bach on Computer]

12 hours ago, Miska said:

It is not clear what are you exactly trying to do? What are your exact settings?

 

 

As first thing I would take either HQPlayer or Mutec out of the picture. Just choose which of the DSP you want to use. But don't combine these two.

 

Hi, Jussi:

 

Thank you again for your helps here.  
 

The settings for HQP are at relative low levels to keep everything simple. 
 

PCM 

1X:  poly-sinc-lp

Nx:  poly-sinc-lp

Dither: NS1

Sample Rate: 96k

 

SDM

1x: poly-sinc-lp

Nx: poly-sinc-lp

Modulator: DSD5

Bit Rate:  44.1K*64

 

It worths noting that Metrum/Sonnet DACs do not have DSD decoding capability.  Mutec USB 3+ can decode DSD256 and deliver a PCM of 176KHz through AES/EBU.
 

Here are the results of playing a DSD file under different scenarios:

 

Mac through USB to DAC: PCM is working

Mac through USB to DAC: SDM, not tested due to DAC lack of DSD

 

Mac through USB to Mutec: PCM is working

Mac through USB to Mutec: SDM is forced to be delivered as PCM to work. (Quite a big surprise to me here, as I never tried this configuration before!)
 

Mac through NAA to Mutec: PCM is working

Mac through NAA to Mutec: SDM works (with HQP version 16.1) or stutters (with HQP version 16.2 and beyond).  This is the key concern for my posting here in the past two days.

Current Network Audio Daemon 4.2.5 according to SotM web site with the latest firmware update.  

 

Thank you again!

 

[eboy]

On 12/17/2022 at 5:14 AM, Miska said:

 

Are you experiencing some specific bottleneck? Sounds like this combination should perform pretty well for many setting combinations. Although two or three more cores wouldn't hurt. Are you experiencing CPU being close to the max?

 

The i7 7700k and rtx 2080 ti are working with sdm | poly-sinc-gauss-xla | ASDM7ECv2 -> 12.288M up to pcm 192khz (cpu=35% & gpu=49%), not pcm 352.8khz (cpu=18% & gpu=99%) and choppy sound.

[bogi]

3 hours ago, eboy said:

The i7 7700k and rtx 2080 ti are working with sdm | poly-sinc-gauss-xla | ASDM7ECv2 -> 12.288M up to pcm 192khz (cpu=35% & gpu=49%), not pcm 352.8khz (cpu=18% & gpu=99%) and choppy sound.

The manual about gauss-xla says: "For SDM outputs, processing is two stages with 16x intermediate rate". It is more CPU demanding to perform 16x upsampling from 352.8k than from lower sample rates. It is not (only) about percent of CPU utilization but it is also about CPU frequency since it is about real time processing. CPU may be utilized to 50% but it may be insufficient to perform some demanding real time processing enough quickly. On higher CPU frequency the same processing could be finished in time so no dropout occurs.

 

On your place I would try poly-sinc-gauss-hires-mp instead of gauss-xla on high input rates like 352.8k. You can also try ASDM7EC, ASDM5ECv2 or ASDM5EC instead of ASDM7ECv2, if they work for you with gauss-xla on 352.8k. Hopefully you can find a combination with sound character and quality which fulfills your exceptations.

Edit: You could also try to 'half tick' (instead of full) the CUDA offload checkbox since 99% GPU could indicate some bottleneck on GPU performance side in your 352.8k use case.