Convolution Filters and Headroom correlation

Hi, I am an electronic engineer but been out of it for many years (I work in software now). Bear with me.

Why convolution filters would need headroom adjust. I guess that will be maybe a case if you work at lower resolutions (say 16 bits)??? I am using filters generated by HouseCurve and they work fine. I started with headroom adjustment of -6db but found out that -3db works fine and there are no clippings (I have the Show Clipping Indicator ON). So far so good using -3db. But still I wonder why there there would be so much enphasis. I guess in recordings that use the bitspace to the max (high dynamic range, less bitspace).

Must be the arithmetic operations and their resolutions I guess.

Someone enlighten me please.


The problem arises, if the convolution response contains a frequency range with a boost and you play a recording that contains a full scale signal within said range.

I would say more a dynamic range topping recording rather than something to do with frequency. That means the levels, not frequency.

I guess the filters do a lot of multiplying and therefore the result needs more bits

It’s not got anything to do with dynamic range, it’s about the absolute peak values only.

You can have wide dynamic range recordings that top out at digital zero decibels at certain frequencies, just like as with dynamically crunched ones.

Roon’s DSP Calculations are done with 64 bit floating point math, then are resampled and dithered to match whatever’s configured.

But anyways, have a filter with gain and it will clip samples that are at full scale, believe me.

1 Like

I haven’t tried 0db headroom but how do you define clipping then? That would be any sample that exceeds the bit space (16 bit for example). Or not? Clipping is anything that tops the bitspace, say 16 bit or 24.

I am at a loss here. Absolute peaks have to do with dynamic range, or not? Maybe I am missing something


You seem to be confusing loudness with dynamic range.

Many of the worst offenders exacerbating digital clipping in DSP are highly compressed, very low dynamic range recordings that are peaking at 0 dBFS almost constantly.



No I am not. I would like to hear your whole point. If you go s multiply the result will be with more bits. Loudness is a non entity here. We are talking about bitspace usage. This is independent of what you use to broadcast the sound.

The above is wrong in actual practice. Because dynamically squashed recordings are the ones that cause the most problems with digital clipping in DSP.


As I wrote, all of Roon’s DSP calculations are done with higher bit depth, decimated to the configured bit depth afterwards, then dithered to avoid audible quantization errors.

And before you ask, taken from German Wikipedia, here’s examples of bit depth decimation without dither …

1khz no dither

… and with dither …

1khz dither

The convolution files created by HouseCurve mirror the EQ settings applied by HouseCurve and therefore may include boosts in certain frequency ranges.
You can easily see this in the graph itself (anything correction above the target curve is a boost) or by exporting the EQ settings as a text file (+ xy dB values are boosts).

If the filters are applied without headroom management activated in Roon, those boosts will cause clipping, if the recorderd signal level in a certain frequency range + the apllied boost by the filters exceeds 0dB, as this marks the maximum possible level in the digital domain.
For example the signal level at 100 Hz temporarily reaches -2 dB, the filter applies a boost of +3dB in this region, so the signal is clipped at 0dB and distortion occurs.

Recordings with a lower signal level, that do not make full use of the dynamic range offerd by the digital media, might not clip even if no headroom is apllied.
For example, if the peak value of the recording doesn’t exceed - 3dB, it won’t clip even if a +3dB boost is applied since the recording offers some inherit headroom.

Adding more bits during calculation doesn’t change that, the added dynamic range that is offered by more bits only allows for lower signal levels, not for higher.
Each extra Bit expands the possible dynamic range by 6 dB to the bottom, not to the top.
So 16 bits allow for a dynamic range of -96 dB to 0 dB
24 bits allow for a dynamic range of -144 dB to 0 dB
and so forth.
This way the original signal is preseverd during the calculation process without “losing bits to the bottom” when lowering the signal level.

Thus negative headroom is needed to avoid clipping when applying Filters with positive boost. A good rule of thumb is to apply the maximum boost value of the filter +2 dB reseve as negative feedback.


Still, if you multiply, the result will be beyond your current bitspace.

Thank you for your throughout response. I understand your response very well (I think) and, would say then. that if the corrections are not so heavy then the headroom required for them (for the emphasis on certain frequencies, etc.) will be less, Probably my case, which would point to a very good setup to start with (hahaha). Cheers!

So, the reason is very simple and headroom would just take care of the emphasis.on the certain frequencies? and not just a function of the filter itself? Is that it? Question for the DSP experts among us (not me of course, haha).So, if I run a filter with no emphasis at frequencies, still I will need to adjust the headroom???

Of course, but I tried to make it clearer to the OP, that using 64 bits for the calculations provides extra 40 bits for the multiplications to not go “beyond the current bitspace”.

But then, since DACs can’t usually handle 64 bit floating point, the result needs to be decimated to the target bit depth and dithered to avoid audible quantization errors.

So what happens, when multiplying two 16 bit values?
You get a 32 bit value!
It’s even got plenty room within a 64 bit space, no?

No boost, no headroom needed, it’s as simple as that.

Now, that reads more like OCD to me, unless you’d care to mathematically explain it.

Correct, if the filters only apply negative gain (attenuation), there should be no need to engange headroom management to avoid clipping.

For example, convolution filters created by the FocusFidelity Filter Designer have the necessary headroom adjustment “baked in” so they apply only negative gain to the signal. This way they can be used without extra headroom in Roon even if certain frequency areas are boosted in relation to other frequency areas.

Maybe there’s a misunderstanding here, of course i meant to write: “negative headroom” instead of “negative feedback”.

I was just trying to give the OP a good point to start with for headroom adjustment, that avoids clipping without sacrificing too much signal level.

The + 2 dB extra reserve should take care of the possible boost values, that exceed the maximum boost of the filters you can identify by eyeballing the graphical representation of the correction curve in the HouseCurve App or by taking a look at the EQ values inside the exported text file.
For example, if two filters with positive gain are applied in frequency ranges close to each other, the individual gains will add up in the overlapping range and produce an even higher gain in this area.
HouseCurve sometimes makes use of this “trick”, but mostly to compensate for large boosts that exceed the maximum correction value defined in the eq settings, not so much for dips.

Not necessarily. As you pointed out before, Roon calculates with 64 bit floating point values.
Opposed to fixed point values that are used to encode PCM data, the value range represented is not limited by the bit depth, but the possible value resolution is limited.

I.e. the value range of 16 bit fixed point is limited to the well known number space 0 - 65535. Any calculations beyond that range are not possible.

Floating point values (in the decimal range, which is more easily understandable) work with a fixed precision value like 1.234567890 in combination with an exponent (10^x) to scale the actual value. The bit depth defines the number of digits after the point and therefore the precision of the floating point which only approximately represents the actual value. This allows for a much larger number space than the actual bit depth would be able to represent at the cost of precision.
But with 64 bits floating point, precision is not a concern in Roon.

So does HAF but I still need to apply headroom in Roon as it still clips on certain content regardless.

1 Like