HQPlayer + Computer vs DSP architecture

[klettermann]

I’ve only recently become aware of a very different digital audio system design approach, and I’m trying to sharpen my understanding of how it compares with a more conventional appliances+loudspeaker-centric architecture. For context, I’m coming at this primarily from a loudspeaker and room acoustics perspective. My own setup uses a MiniDSP SHD Studio to handle room EQ, bass management and delay alignment before the DAC. In other words, the digital chain is organized around controlling the acoustics and getting the best result from the speakers, subs and room. So, with that in mind, the two architectures I’m trying to compare conceptually are:

Architecture 1 (DSP-centric loudspeaker system)
Digital source → DSP device → DAC → amplifier → speakers

Architecture 2 (HQPlayer-centric)
File → computer running HQPlayer → DAC → amplifier → speakers

In the first case the DSP device is performing functions such as room EQ, crossover/bass management, delay alignment and subwoofer integration before the signal reaches the DAC. This approach tends to rely heavily on measurement and acoustic optimization. In the HQPlayer model the heavy processing happens upstream in the computer: oversampling filters, modulators and conversion to very high-rate PCM or DSD before the DAC performs final conversion. Also, my general sense is that the HQP crowd often ignores room treatment, subs, modes etc. Obviously I may be completely wrong on this.

Anyway, these two approaches appear to emphasize very different parts of the playback chain. So the questions I’m trying to understand are:

1. Are there measurable differences at the analog output of the DAC between these architectures that would reasonably survive the loudspeaker and room?
2. Are there credible audible or measurable differences between reconstruction-filter or modulator choices (HQPlayer-style processing) once the signal passes through speakers in a room?
3. How should the magnitude of those effects be compared with the effects of room correction, bass management and subwoofer integration?
4. Are these really competing architectures, or are they simply addressing different layers of the playback system?

To be clear, I’m not trying to start another format war. I’m mainly trying to understand the design philosophy behind the HQPlayer/computer approach and how it compares with a DSP-centric loudspeaker system architecture. Hope this makes sense. Thanks and cheers,

 

[Kal Rubinson]

Anyway, these two approaches appear to emphasize very different parts of the playback chain.

1. Since (1) is actually changing FR, timing, etc., its effects on the analog output are measurable at the DAC and, also, from a microphone in the room. Approach (2) may also produce measureable effects at the DAC output but I am doubtful that they can be discerned from in-room acoustic measurements.

****************Added in edit: The signature features of HQPlayer are what distinguishes it but it can also support other DSP. OTOH, those other DSP functions do not require HQPlayer. ​

2. Ask Miska.
3. By measurement (see above) and by blinded, controlled listener testing.
4. AFAIK, they have entirely different goals. One (HQPlayer) is attempting to improve the signal (independent of the room and speakers) while the other (Speaker/Room EQ) is attempting to optimize the performance of the speakers and minimize the influence of room acoustics.

 

[3ll3d00d]

There's no architecture 1 and 2, just different pieces of software with different feature sets. Afaik hqplayer still had all the usual dsp features like iir filters and convolver , it just also has a bunch of other features that tend to appeal to a certain crowd.

 

[SuicideSquid]

I’ve only recently become aware of a very different digital audio system design approach, and I’m trying to sharpen my understanding of how it compares with a more conventional appliances+loudspeaker-centric architecture... My own setup uses a MiniDSP SHD Studio to handle room EQ, bass management and delay alignment before the DAC. In other words, the digital chain is organized around controlling the acoustics and getting the best result from the speakers, subs and room. So, with that in mind, the two architectures I’m trying to compare conceptually are:

Architecture 1 (DSP-centric loudspeaker system)
Digital source → DSP device → DAC → amplifier → speakers

Architecture 2 (HQPlayer-centric)
File → computer running HQPlayer → DAC → amplifier → speakers

I think it's important to note that these really aren't two different architectures, just two different pieces of software. A MiniDSP SHD Studio is just a computer running custom software. A PC, a Raspberry Pi, or custom hardware like a MiniDSP can all functionally do the same thing, if they're running similar software.

You can have a PC or RasperryPi set up to run HQPlayer, and also to run REW, EqualizerAPO, or other room correction/bass management/EQ software.

Personally, I don't think there's much to be gained by oversampling and up-converting digital audio. Repeatedly re-sampling a PCM file just risks introducing additional noise and jitter artifacts into the signal.

 

[ZolaIII]

Look imagine you're self as a little girl called Pandora and you open a mini box you have.
Seriously HQ player and... It's not to that you get 20+ years of DAW plugins legacy and new stuff you want to integrate alluding to versatility and adoptability. Player is there as you won't play music trough DAW and let it be JRiver for ISO 226 2003 ELC support.
2. Will be dependant on quality and resolution of filters so yes.
4. They aren't competing in this space where you don't really need very high parallel general purpose CPU cores won with IE Float standard adaptation and FPU fixes. They don't compete in high space either where ADSP's win 5~6x times but are harder to program up to GPU's and AI accelerators. They lose to ASICS for defined tasks (not programmable).
Wery most of mastering is done in DAW's for a very long time now so there is that. The increase in complexity turns off many people but there is no other way to get some things and toys.

 

[Keith_W]

As others have said, architecture 1 and 2 are the same. It's just different computing devices and different software with different features. And FYI it is possible to use HQP Embedded to create your own "DSP device". HQP Embedded has its own Linux-based OS and does not require a separate install of Windows or Linux. Once you DIY your own PC boxen and install HQP Embedded, you can think of it as a hardware DSP, just like a MiniDSP which has tonnes more computing power, but also complexity, cooling fans, and more points of failure.

Both HQP and HQP Embedded can work as a linear-phase FIR convolver, so you can load DSP filters and have HQP do your DSP for you. I am not sure if HQP can do IIR biquads, I haven't checked the feature list recently.

Are there measurable differences at DAC output? This depends on your DAC. I have measured a 4dB improvement in SINAD between PCM 48kHz and DSD256 with my DAC, from 114dB to 118dB. Is it worth pursuing this improvement? IMO the answer is a big fat NO. The difference in SINAD is swamped by everything else in your audio chain, not to mention the room's noise floor, and especially by the DSP. But for some people, the difference helps them sleep better at night given that they have pushed something inaudible into something slightly more inaudible. As @3ll3d00d says, "it's for a certain crowd".

Do note that if you want DSD processing, you will need a LOT of CPU power. We are talking gamer-style PC's with an nVidia video card with CUDA cores. And HQPlayer is not cheap either. I know all this because I specifically bought my Merging DAC because it's capable of DSD and I wanted to use HQP with a powerful PC to use DSD upsampling and filter convolution. After I spent all that money, I honestly couldn't hear a difference between DSD256 (which put my PC at 80-90% CPU usage!!) and PCM48 (2% CPU usage).

IMO going down this route is a waste of money. I get that in some circles, bigger numbers = better. But trust me, 44.1kHz is all that you need.

 

[john61ct]

I'm at a similarly early stage and enjoy "classifying matrix" factors.

On the one hand we have the "functions and features" aspects, some are not DSP - specific, including some aspects that CAN be done without DSP.

Then there is "platform", what does it need to run?

bandwidth / horsepower needed, or inherently limited?

...

Within DSP:

Mostly just measurement vs

mostly design filters vs

convolver included or separate?

What type of filters?

Then issues like DSP-Noob-friendly? some take years to learn, or you hire an expert to help

Compatibility with other tools, import/export format?

Automation or manual grind?

specialist ICT skillz required?

And finally, financial investment required, including both the software, ICT type hardware vs proprietary boxen, licensing fees, cables / microphone / preamp / interface...

 

[elguapo]

I’m mainly trying to understand the design philosophy behind the HQPlayer/computer approach and how it compares with a DSP-centric loudspeaker system architecture.

HQPlayer can also function purely as a DSP engine — with real-time I/O, FIR convolution, and IIR PEQ (including biquads @Keith_W ). It’s a software DSP solution that runs on hardware ranging from something as modest as a Raspberry Pi 4 all the way up to the most powerful mainstream CPU + NVIDIA GPU workstation that money can buy. More computational resources simply allow for heavier LPFs, longer FIR taps (ever tried million-taps FIR room correction? ), higher DSD rates, and / or additional channels.

In contrast, the miniDSP SHD Studio is an embedded hardware DSP — convenient for integration but with relatively fixed processing capabilities.

Not to mention that once the audio data is upsampled to DSD, it bypasses any further DSP processing and goes straight to the DA stage. Fewer DSP stages always benefit sound quality.

 

[ZolaIII]

Only PCM to DSD software is now quite old and writen SMP 4 (dosent benefit from more than 4 cores) so it doesn't quite need a modern CPU with many cores nor benefit from its FPU or SIMD capabilities, it needs fast OoO cores. You don't need that! You are good with PCM 24 bit. If player supports floating point internal processing for manipulation purposes use it, it will be converted back to PCM integer (to selected bit depth precision) and go to DAC. Avoid using high end gaming system (it will produce lot of EMI under heavy load) or use it but feed DAC from it with Toslink.

 

[MaxwellsEq]

I’m mainly trying to understand the design philosophy behind the HQPlayer/computer approach and how it compares with a DSP-centric loudspeaker system architecture.

There is a school of thought that considers PCM is inherently flawed and has an audible "sonic character". I believe that this has not been proven in blind testing.

There's a subset of that viewpoint that considers the DAC brick wall reconstruction filtering at half the sample frequency impacts sound quality, especially if that sample frequency is 44.1kHz. This may be possible (I wish CD had been at least 48kHz). One "fix" for this problem is to upsample and then use "better" or gentler filters a long way from the highest audible frequencies. There may be some blind testing that proves this is beneficial, but I've not seen it.

Some of this thinking seems to completely ignore the ADC used in recording!

If there are benefits to this approach, they are likely to be quite small. They will almost certainly be smaller than the benefits gained from taming a resonance in the listening room.

 

[ZolaIII]

@MaxwellsEq there are many ways to EQ highs but it won't work if they aren't in focus (beeming). I whose hopping avoiding another tap vs CPM discussion. It's too a precision of matrix and we don't nead more then 19 bits anyhow. Problem of DSD it's devider is 16 bit to 44100/48000. Noise shaping beyond audible threshold is as valid technique as it's dithering. DSD128 is in line to 19 bits to audible spectrum it whose closed source not friendly in any way and neither should be used anymore or anything stored with it can be bit exact converted without filtering (you nead to apply filters you're self during reproduction same as you would with DSD) to PCM and future loseles compressed much better.
Where tap based modulation is dominating for it's simplicity are ADC's as a transport protocol of course and not aiming at stars regarding performance and that won't change. At least 80% ADC's are like that from smartphone to TWS to what ever you might or might not imagine. FIR is tap based and so are all our measurements and so on.

 

[elguapo]

If player supports floating point internal processing for manipulation purposes use it, it will be converted back to PCM integer (to selected bit depth precision) and go to DAC.

If you're using a Sigma-Delta DAC, you're going to have another round of quantization error (QE) anyway. Why?

Because the chip still has to internally upsample your 24-bit PCM and run its own noise-shaper/modulator — that's a second full quantization step on top of the one you already forced when you converted FP32 or FP64 back to integer PCM.

If you keep the DSP pipeline in FP32 or FP64 and output native DSD directly, you can avoid those two (or even three) rounds of quantization entirely.

 

[Blockader]

If you're using a Sigma-Delta DAC, you're going to have another round of quantization error (QE) anyway. Why?

Because the chip still has to internally upsample your 24-bit PCM and run its own noise-shaper/modulator — that's a second full quantization step on top of the one you already forced when you converted FP32 or FP64 back to integer PCM.

If you keep the DSP pipeline in FP32 or FP64 and output native DSD directly, you can avoid those two (or even three) rounds of quantization entirely.

The claim that you "avoid quantization entirely" by outputting DSD is false. DSD is quantized: it's 1-bit at a high sample rate (for example 2.8224 MHz for DSD64). You haven't avoided quantization, you've just moved it upstream into software and done it once instead of twice.

The more fundamental problem is the implied significance. 24-bit PCM has a quantization noise floor around −144 dBFS. That's roughly 20 dB below the thermal noise floor of the best analog electronics and far below any audible threshold. The "second quantization step" the argument warns about is adding noise at a level that doesn't exist in the physical world in any meaningful sense.

There is one more thing to take into consideration: Thermal noise. - 144 dBFS is something electronic devices can only reach when the room temperature is around - 261 degrees Celcius.

 

[ZolaIII]

If you're using a Sigma-Delta DAC, you're going to have another round of quantization error (QE) anyway. Why?

Because the chip still has to internally upsample your 24-bit PCM and run its own noise-shaper/modulator — that's a second full quantization step on top of the one you already forced when you converted FP32 or FP64 back to integer PCM.

If you keep the DSP pipeline in FP32 or FP64 and output native DSD directly, you can avoid those two (or even three) rounds of quantization entirely.

Yes will have it anyway but you ain't introducing any on FP or back to integer (you are but you can use much higher matrix one, two orders of magnitude and introduce so little that it doesn't mater when you cut precision down drastically). Simply said you have unreal huge SINAD freedom to do what ever you want and still glue it back to integer precision limit. FP 64 is also called double precision or scientific precision and there is no higher used for anything nor will be. When you need accelerator and nead very lot of it to do complex weather simulations for example you pay it in gold for a GPU that doesn't have it deliberately cut down and you don't want to use it when it comes for free to you.

Edit: there whose rounding back integer overflow errors which even needed EI Float standard changes and FPU patching and represented a problem but only before it meet wider use and all whose finalised (standard and hardware support).

 

[elguapo]

The claim that you "avoid quantization entirely" by outputting DSD is false. DSD is quantized: it's 1-bit at a high sample rate (for example 2.8224 MHz for DSD64). You haven't avoided quantization, you've just moved it upstream into software and done it once instead of twice.

You mis-interpreted my post. Please read it carefully. I said "avoid those two (or even three) rounds of quantization" is the same meaning as your "done it once".

 

[klettermann]

Wow, many thanks to all! This did help gel things for me. My key takeaway is that the architectural distinction is real, but it is not actually about hardware per se. It is about optimization target. Here's how I see it:

Case 1, MiniDSP worldview (me) : digital source → DSP → DAC → amp → speakers → room
The optimization target is the acoustic output of the system in the listening room.

Case 2, The HQPlayer worldview: file → heavy digital processing → DAC → amp → speakers → room
The optimization target is the digital signal arriving at the DAC.

Those are fundamentally different priorities and the magnitude of the effects is radically different as @Keith_W points out. So, yes, technically the software could run on the same machine. But system architecture is defined by what the processing is trying to optimize. IMHO then (and bluntly stated), the rational engineering order of priority would be:

1. loudspeaker quality
2. room acoustics / modal control - positioning, room treatments, DSP: EQ
3. subwoofer integration - DSP: Timing, EQ XO
4. DAC linearity
5. Digital filter minutiae

What I still don't get is the apparent inversion in "certain circles." Perhaps the core of it actually computer/data/IT hobbyism that happens to feed loudspeakers? If so, that would clear it up for me.

Anyway, my path forward is pretty clear: keep all my stuff and continue with room improvements. Now underway are panels to improve impulse response. After that will come another look at EQing and response slopes. On the signal side it would seem to make sense to minimize conversions to extent possible. The MiniDSP processimg is fixed at 96Khz and it up/downsamples the inputs accordingly. I can't do anything about CD or DAT inputs. But I can set my streamer to output 96Khz. I doubt any of that would actually be audible, but why not?

Further comments and flames welcome! Thanks to all and cheers,

 

[Keith_W]

What I still don't get is the apparent inversion in "certain circles."

Very simple. Misplaced priorities. I wouldn't say that HQP is at the same level as snake oil since it actually does do something, and there are measurable differences. But as for audible differences, it may as well be snake oil.

 

[john61ct]

One key principle I'm struggling with, is the idea integrating the DSP convolving into player software.

This seems the very definition of lock in, extremely limiting.

My goal is modularity, different components can be swapped in & out depending on context, my preferences at the time, without affecting (much) the rest of the system.

And complete flexibility wrt sources is a hard requirement, whether analog or digital.

 

[ZolaIII]

One key principle I'm struggling with, is the idea integrating the DSP convolving into player software.

This seems the very definition of lock in, extremely limiting.

My goal is modularity, different components can be swapped in & out depending on context, my preferences at the time, without affecting (much) the rest of the system.

And complete flexibility wrt sources is a hard requirement, whether analog or digital.

Look with plug in suport any player can become DSP, there are plug in's containing whole DAW (in single one). Not telling you should go that way but you can find pretty much good quality anything you might need (and plenty of things you might like) and mostly for free or in non commercial purposes so. Same is with new stuff and stuff that will come, somebody will make software plugin to do it because he needs it. You pay up keeping it (PC/laptop) but if it's deticated machine only for that and quite frankly you don't do much more than let it run down already done preset that will really be minimal.
Rack mont equipment will never go anywhere but today again that's much more pro segment and no one is stopping you buying such. To hell you can even remotely control and operate one PC on a another. We live in time when you can low latency encode, send, reciver and decode high quality 4K HDR10 video over network or Wi-Fi while sending controls back in 45+ FPS range (regarding latency).
The player escape box or inserting it on system lv will depend and mostly be based on exploit. Different operating systems, different exploits. Don't know for Apple side, for Windows mostly trough WDM, on Android trough accessibility framework. Regarding plugins compability for VTS will be on Windows/Mac OS side. On Linux of course you don't need exploits, VTS support is on going and compability is not great and same is regarding driver's.
As a pro and for pro work base frame won't be player but DAW and you won't try to hijack the system in the first place.
I am trying not to get into details would be too much for the opus of this but I think it's enough to get you a see bigger picture.

 

[john61ct]

"classifying matrix" factors.

First attempt, applied to Acourate

ASR Acourate users

So bass management is the function category for all that. With "phase / delay issues" mostly a part of that as opposed to "Custom designing speakers from separately driven drivers" ? aka "bi- or tri-amping" which I expressed not a current goal for me. So, add speaker / room compensation EQ...

www.audiosciencereview.com