PEQ in Roon's DSP leads to clipping on some bass heavy tracks

If it’s what I think it is, @Brian’s covered this previously - something about the filtering maths leading to very slight clipping even in cases where the PEQ is set to zero (or a reduction like you’re doing). I can’t remember the exact details.

That said I’m surprised you need 3db headroom. For me it was just 0.5 or 1db needed so maybe it’s something else.

Yes. This is always possible with EQ, even if the EQ curve is completely below the “0” line. The EQ function affects the sound as a whole in a way that reduces energy, but the math can produce individual sample values that clip slightly.

The same same goes for upsampling–which doesn’t change the amount of energy, but can result in “inter-sample overs” if the interpolated waveform clips.

This effect is most pronounced with minimum phase filtering in both cases. Our PEQ is minimum phase, as are some of the upsampling algorithms.

Nothing has changed in either area in quite some time, so I think whatever you are running into is not caused by the latest build.

In short, use headroom. That’s what it’s there for.

I also experienced clipping even when doing below zero equalization, but an interesting question is this: will that type of math-overflow-clipping (or whatever to call it) actually affect the sound quality?

“Maybe”

Personally, I don’t want any samples clipped during playback, ever, because it’s not easy to determine when it’s doing audible damage, and I don’t want to have any doubts. It’s also very easy/cheap/transparent to create some headroom.

It’s very common for both hardware + software products to do this sort of processing (upsampling, IIR filtering) without headroom and without a sensitive clipping indicator. These products typically flat-line any out-of-range samples digitally without giving any feedback. Clipping samples always produces some distortion.

This required careful consideration when building our clipping indicator. Most clipping indicators do not indicate single-sample clips like ours. We first released the clipping indicator to alpha without an “off” switch, and a lot of people immediately ran into this issue while playing with DSP.

This was concerning, because we weren’t doing anything different/worse than anyone else, but the ugly red light was making it seem that way. Other apps/products just silently clip the samples.

The reality is, if you want to pay attention to a super sensitive clipping indicator, you need to pay attention to the headroom topic as well. That is why they are tied together in the UI. Yes, it’s possible to turn on the clipping indicator with 0dB of headroom, but it’s several clicks deep for a reason.

Additional headroom may also have a positive impact on downstream processes, too. Many DACs upsample internally. Plus there’s the whole analog domain side to worry about…

I know of one DAC manufacturer (Benchmark) that considers the handling of inter-sample peaks to be critical enough for sound quality that they create 3.5dB of headroom in the digital domain ahead of signal processing. They did a writeup on that here..

2 Likes

I’m not sure how common it is, but an inside source suggested that Devialet process data in a way that saves the speakers from clipping damage, so when you see the Devialet clipping indicator (pretty rare I have to say) it’s actually safe. The term they used was “elliptic compression”, which I assume is some sort of ‘soft’ or ‘feathered’ clip.

I don’t have much knowledge about it or whether it’s definite as it was a forum source, but from someone close to the founders.

Would this be worth building in to Roon, such that clipping isn’t really an issue - at least in the sense if you ignore it you’re protected? Thinking more about people that are less technically minded/interested but will still dabble in DSP. Or maybe you already do it?

Roon clamps the samples when they exceed the bounds, so there is no concern about damage. The clipping indicator is informing you that a sample value was limited, not warning that a dangerous sample got through.

All clipping introduces distortion. Soft-clipping creates distortion that is less offensive to the ear, but it is still undesirable. Soft clippers make more sense in systems where you can’t anticipate signal levels in advance. That is not the case in playback software where a small, fixed amount of headroom suffices to totally remove the problem.

Ah ok, that’s my misunderstanding then. For some reason I assumed the clipping process - the sort of ‘hard’ cutoff of the signal even as Roon does it - was also the type that could cause damage to speakers.

Its fine when you have headroom to spare…however I use DIRAC which already has a -6db digital reduction. I too implemented a HP filter -, a 4th order starting at 22hz and this too gave me almost a constant clipping indicator on bass heavy stuff and it required -4db more to extinguish it. 11DB attenuation is a LOT … its difficult to determine if the clipping is audible as you have to turn off the headroom to hear if it is and if you do so the signal is much louder

I too was most surprised as I was boosting NOTHING. I dont think its a good thing to have to implement attenuation when only cutting in the digital domain

PS I took my dirac attn down to -10db … hoping that I wouldnt have to use headroom reduction in Roon…no joy … I thought dirac might be causing the clipping , but not so

It’s not really a good or bad thing…just the nature of the math involved. There really isn’t much subjectivity to the implementation of a traditional IIR-based parametric equalizer.

Most implementations simply ignore this kind of clipping, limit the handful of samples that clip, and move on. That is an option with Roon, too–just turn off (or ignore) the clipping indicator.

Whatever the reasons, it does feel very odd that reduction of sound level through DSP causes clipping. Is it like small spikes that causes the clipping, and if so than the clipping would actually improve sound quality since clipping would reduce the spike-errors.

Or does the clip indicator uses intermediate results, like after one filter but before another that cancels the sound that would cause clipping,

However, a good trick to reduce or eliminate clipping is to use volume leveling. For me, after room correction that mostly lowered volume, only the sound of a plane crash on Roger Waters - Amused to death causes clipping as far as I have noticed.

The clip indicator detects clips either:

  • When reducing sample size from 64bits down to 24 or 32 or 16 bits for transmission to the DAC as PCM
  • Right ahead of the sigma delta modulator if playing DSD

These have something in common: they are the last thing that touches the signal. It would be inappropriate to clip intermediate results for the reason you suggest.

@brian, I know the Roon preference is for fewer settings, but perhaps you could consider adding a clipping ‘sensitivity’ setting:

‘Default’ - ignore the kind of clipping you say others ignore, so the warning flashes only when things are seriously clipping.
‘Precise’ - show everything.

That way people wouldn’t lose the benefit of the indicator, but it wouldn’t flash away until things get bad to the point where they really should do something about it.

I would love to see some sort of flag for when things have clipped in the past too - I’m not always watching the signal path, but would like to know if anything I played has clipped at any point. Probably not an easy one to display nicely. I only mention this as I thought I had generous headroom, but every now and then a track flicks the light on when I’m looking.

I’m not fundamentally agaist the idea of a setting here, but “bad to the point where they really should do something about it.” is really subjective.

As far as I’m concerned, any clipping deserves attention, and most DSP requires headroom in order to operate at its best. That idea is reflected in Roon. The thing you see when opening DSP Engine for the first time is educational text about Headroom Management and a single click that enables it and sets it up sensibly.

We are not the only product with this opinion. HQPlayer shares it, but takes a different approach in the UX–if you try to set the volume knob too close to maximum, the knob turns yellow, then red. Regardless of clipping. Basically, unless you want to live with an ugly red knob, you’re forced to make some headroom.Same idea–DSP needs headroom.

I guess what I’m missing is: why is your answer “make the sensor less sensitive” instead of “make adequate headroom for my DSP”?

History for the clipping indicator is an interesting idea.

Just because you say some other programs (the consensus?) ignore the ‘fine’ clipping and it crops up from time to time on the forums. If it makes no audible difference and can be safely ignored then making it less sensitive would stop it cropping up. People simply turning it off sort of then leaves them ‘unprotected’ from serious clipping. Ie I’d be happy to not know about tiny inter-sample clips or whatever they are but would still want the light to go red when I was genuinely setting up dsp or making adjustments.

The idea behind it being its simpler to make it less sensitive than automatically adjust people’s headroom or explain the intricacies. :innocent:

But I see your point - who decides what’s audible? I’m guessing there’s not a person alive that could detect a clip of the type you’re explaining to Rodney and the rest of us?

Actually, doing an automatic headroom adjustment doesn’t seem like a bad idea. Maybe that’s better than the ‘-3’ default. Each time we run into a clip, auto-adjust it by the amount that would have avoided that clip, perhaps with a gentle ramp. At some point, based on your settings/source material, it will stop moving. Raises a question of what to do if DSP settings change…deserves some thought. Maybe there’s a max adjustment that it’s willing to do before it stops adjusting and “lets clips through”.

What’s interesting about that idea, is that it might enable a world where we could turn the indicator on by default. Which would be more in keeping with the mission here–which is to stop people from experiencing Roon’s DSP with any potential clipping-induced distortion.

Unfortunately, it could still make Roon “sound worse” just because it’s quieter. Some people will always hear quieter as worse, and our SRC would not stack up well in some comparisons if it had a permanent, non-disable-able gain adjustment baked in, simply because “quieter” has a larger effect size than this issue.

Deserves some thought in any case…

Surely it is possible to check and save highest allowed amplitude/frequency when building the audio library, and then from that calculate a headroom, so that Roon could suggest the highest sound level that would not produce any clipping in the library you have.

Of course, this would not include Tidal songs, but it would certainly be a good starting point for headroom management, or as an option for automatic volume leveling.

Clipping is going to depend on what DSP you apply.

1 Like

Yes of course, but if you save the required information during library tune-processing, you can add a “suggest headroom” function that uses the current DSP to provide the highest volume that wont create any clipping in your library.

Or if using this feature as part of volume leveling (which would be neat), just refresh the calculation or maxgain whenever DSP is changed.

This is not possible without re-processing the whole library through your current DSP settings each time they change.

[quote=“brian, post:24, topic:30158, full:true”]
This is not possible without re-processing the whole library through your current DSP settings each time they change.
[/quote]Oops, don’t ever say “thats not possible”, say its vert hard and complicated instead. As a developer I know you often ends up having to take it back :slight_smile:

I know the convolution/DSP issue is not straight forward, but we are talking about numbers here (typically 16 or 24 bits long), and whether new values after DSP is to high to fit in those 16/24 bits. So an overflow check given than you know all max values from processing your library, and your new DSP, is certainly theoretically possible. But I know to little about DSP and convolution to take a guess if its practical and easy to implement!