HQPLAYER new Version 5 Discussion

If you have true high res 96kHz track with content above 24kHz, then if you do not enabled HF Extend and you use only 48kHz DRC filter → then you will not have any 24kHz content output from your DAC. As Jussi wrote above.

That is the purpose of HF Extend , see the screenshot I shared above explaining by Jussi

If you use 353kHz matrix filters, you don’t have to worry about HF Extend option, it can stay disabled

You didn’t get my point. If you design a 48KHz FIR filter with LP at, for example, 22KHz, the HF Extent will become an option no matter the source sampling rate is because the music contents will be cut at 22KHz intended before the HF Extent functional even the FIR filter resampled to match the source sampling rate.

1 Like

For someone who is using 8-9 filters per channel, what is the best technical solution (better quality and/or less resources)? Load the filters as PEQ, or create an impulse response and load them as convolution?

What is the source of these filters? If it is for example REW, then load the filters as PEQ.

PEQ is also sampling rate agnostic. So it doesn’t need any handling to deal with different sampling rates. And if you use the IIR to FIR option, you can choose to convert it to minimum- or linear phase FIR. Essentially a sampling rate agnostic creation of a convolution filter. This can be more efficient if you have many PEQ sections.

PEQ (IIR) is minimum-phase. Linear-phase may work for cases where you don’t have drastic/steep/high-Q EQ’s within sensitive audio bands, when everything is gentle and low-order. Aggressive EQ as linear-phase introduces plenty pre-ringing in the audio band, which will make sound harsh and in worst cases “zingy”. (this is also why for example REW always creates minimum-phase convolution filters as well)

1 Like

Thanks for the reply. Yes, the source is rew. I am just loading the txt filter export from rew. I don’t know how hqpplayer will treat the file (linear or minimum phase).

There are no high Q filter (the steepest is q=2).

From your reply, I figure it is best to keep as PEQ, and maybe experiment with iir and fir options. Did I get it right?

If you have the IIR to FIR check box blank, then it is IIR which is minimum-phase. When running it as a FIR, you have option to keep the minimum-phase, or convert it to linear phase.

OK, then it is rather gentle one.

Yes, it is best to keep it as a PEQ .txt as you have it. You can experiment with IIR to FIR, also the linear phase option, if you like since it seems that it could work for your case.

Thanks again for your kind reply.

My playback is failing about every 30 minutes. Playback just stops abuptly. This is all that is logged when it happens. Anyone have any thoughts on the failure?

I have HQPlayer running on an AMD 7950x3d with 64GB of RAM and currently no GPU acceleration selected. It is feeding a Holo Red via NAA. The Holo Red is in performance mode so only HQPlayer NAA is selected.

+ 2024/07/14 14:20:46 NAA output network engine started at: 24576000
# 2024/07/14 14:48:15 NAA output clSocket::Send(): send(): Unknown error
! 2024/07/14 14:48:15 NAA output clNetEngine::PushSDM(): clNetEngine::SendStreamSDM(): clSemaphore::Wait() (15372)
! 2024/07/14 14:48:15 clHQPlayerEngine::Execute(): push to FIFO failed
  2024/07/14 14:48:15 Stop request (reset)
& 2024/07/14 14:48:15 Stop...
- 2024/07/14 14:48:15 Playback engine stopped
& 2024/07/14 14:48:15 ...stopped

Here is additional info on the playback chain.

2024/07/14 14:20:46 Play
  2024/07/14 14:20:46 Offload: resampler=disabled convolution=disabled
+ 2024/07/14 14:20:46 Playback engine running
  2024/07/14 14:20:46 IntegratorM: FIR2
  2024/07/14 14:20:46 NAA output set sampling rate: 24576000 (24576000)
  2024/07/14 14:20:46 Automatic output rate: 24576000
  2024/07/14 14:20:46 Engine reinit, rate or blocksize change triggered
  2024/07/14 14:20:46 Rate: 96000, block size: 7680, frame size: 1280
  2024/07/14 14:20:46 Block size: 7680 (sample: 3)
  2024/07/14 14:20:46 Analysis initialized
  2024/07/14 14:20:46 Oversampling: linear phase apodizing Gaussian poly sinc for HiRes
  2024/07/14 14:20:46 Modulator: adaptive seventh order 1-bit super 512+fs
  2024/07/14 14:20:46 Integrator: FIR2
  2024/07/14 14:20:46 Playback engine ratio: 256
  2024/07/14 14:20:46 Channel 0 delay 0 samples, gain 1
  2024/07/14 14:20:46 Channel 1 delay 0 samples, gain 1
  2024/07/14 14:20:46 Multichannel speaker processing disabled
  2024/07/14 14:20:46 Set volume: -3 +

Are you on a trial or do you have a license? Trial period is 30 mins.
Check “About” to see if on Trial or not.

Sorry of course that seems obvious. I have a fully licensed desktop version 5.7.2 running on Windows 11.

Looks like connection to the NAA has been lost here. Seems like a network issue. HQPlayer will try to reconnect right after, but the music playback is stopped. You can check log file for example for possible change of IP address.

Everything is static mapped, so there is no change of IP Address. I just updated the firmware of my Mikrotik networking hardware but the issue persists. I will check for other network issues, but I have no reason to believe my network is causing me issues.

If you are still going through DHCP instead of static IP (no DHCP), then there is also possibility of lease expiring before getting refreshed. What is your lease time?

If you have a smart switch (since you updated firmware), please make sure you have 802.3x Flow Control (aka pause frames) properly active. Usually you can see pause frame statistics from the switch web interface.

Another possibility is that for some reason TCP keepalives fail (for example due to non-functional 802.3x) which would result in disconnection every 30 minutes.

and best regards
I have a question about the last DAS corrections from July 14 and 15.
Where were they added and how to update existing versions.
Thank you

Those are cloud based. With HQPlayer Desktop >= 5.7.2 or HQPlayer Embedded >= 5.6.3, restarting HQPlayer is enough to activate the new corrections.

I had to ask the question… do the DAC corrections only work on the USB interface ?
No way to force a correction (eg for Spring3) which uses HQP and I2S ?

Could you add more context for why these settings may be causing an issue? Flow control appears to be a method for controlling congestion, but there should not be any congestion on my network. Is there something within NAA that requires this? Do you suggest Tx and Rx flow control to be enabled?

Edit: Maybe worth noting I am using I2S from the Holo Red to the Holo Spring 3 KTE. Not sure if this would have an effect.

Over NAA or direct USB connection, but generally only over USB. When S/PDIF, AES/EBU, I2S or any other unidirectional connection is used, there’s no way to detect the DAC at the other side of the connection.

Spring 3 also performs the best over USB.

Because many devices cannot process packets at full sustained 1 Gbps or higher incoming data rate. Without flow control, when they reach the point the hardware packet receive buffer becomes full the only option they have is to throw away the packets. Eventually the higher level protocol notices there are missing packets and requests resend of those packets. This in turn makes the overall situation worse by adding a lot of redundant traffic. 802.3x is implemented at the hardware level and allows the hardware to request upstream device to pause sending packets when it sees it’s hardware buffer becoming full. Usually such hardware buffer is something like 8 - 64 Ethernet frames. When the hardware again sees space in the packet buffer, it tells the sender to continue sending. Thus no packet loss or resends needed… And this is very quick, it can react within time of single 1500 byte Ethernet MTU.

As an example Rendu has 1 Gbps Ethernet interface, but the local bus between Ethernet controller and CPU can pass max 400 Mbps of traffic.

Looking at my switch statistics, even powerful computers like iMac with i9-9900K CPU is actively using 802.3x pause frames to control the data inflow. For example if you need to write an incoming file to a spinning HDD - which can be slower than what the network can push on you. This is also apparent from smooth data transfer speeds reaching theoretical maximums, instead of occasionally stalling transfers that look more like rollercoaster (due to buffer overflows and resends that cause stalls).

Note that flow control is negotiated at hardware level between the devices. Most drivers for computer NICs enable this feature by default, so it becomes active automatically whenever the infrastucture supports it.


Outstanding! Thank you. I’m going to make the changes and try this out.