TOPIC:

I am using this profile with the Sennheiser HD800S headphones:



This is how it looks like:



As you can see, the curve is either at or below 0 dB. I was quite careful to not breach the 0 dB level, so as to avoid distortion.

The IL-DSP is connected via USB to a MacBook Pro (15-inch, 2017), running macOS 10.14.6.

The volume setting on the Mac is at 100%. This is how I always keep the volume on all my systems, and all DACs are fine with it. I rely on the volume control on the amp - always. In this case, I rely on the volume control on the IL-DSP. This is common practice among many headphone enthusiasts. There should be no problem with it as long as EQ doesn't go above 0 dB.

I am listening to the Chillout channel on this site DI.FM . The volume control on the site is also at 100%. This is never a problem with all other DACs.

Surprisingly, with the IL-DSP I still get occasional distortion with some songs, especially during parts that have a lot of low frequency drums and bass, even though I was careful to avoid distortion-causing settings. Moving the volume setting on the Mac one notch down removes the distortion. But this "solution" is counterintuitive because the IL-DSP plugin does not give any indication that distortion may occur. As far as the user can tell from the UI, everything ought to be fine.

This is why I keep saying it's important that the plugin should perform a check of the transfer function, and should tell the user if there's potential for distortion before any signal is ever sent through the DSP.

This ought to be trivial to do in the plugin. You display the EQ curve anyway, that means you compute it. Please add an extra step, and check the output for the worst case scenario input: if the output goes above 0 dB with the loudest legit input, tell that to the user. Highlight the problem section in the frequency response curve. Highlight the filters that might cause it. Do something, anything.

The app should not remain silent if the current EQ curve could potentially cause distortion with some types of input. It needs to be clear on that. "The user ought to know better" is never a good answer to this issue.

Hello FlorinAndrei!

Thanks for reporting, I have the same issue with my IL-DSP, running firmware v1.3.

The EQ implementation faulty, it is not how it should behave.
Currently, if any band EQ band gain is above 0dB then there will be clipping, unless the input signal is offset by an equivalent input gain.
An online generator like www.szynalski.com/tone-generator/ makes testing very easy - make sure volume is set to 100% and system volumes also is.

Attached, my current HD650 and ER4XR corrections: introducing clipping like your correction as well, despite the negative gain of the EQ1 band high shelf should prevent that.

I think I guessed a hacky workaround however: I'll follow up soon after more tests.

Okay so @devteam made a mistake when implementing IL-DSP plugin UI.
Fortunately, there are ways to work around this issue and the current DSP implementation limitations.

It made no sense that clipping occur with the EQs FlorinAndrei and I made since the first EQ band was giving all the headroom necessary for the next ones, even if an integer accumulator was in the biquads's implementation on the DSP side.
Unless... the bands were not sent in the right order, which is exactly what's happening.

There is a bug in the current version of IL-DSP plugin UI which for some reason inverts the band's order:
- in the XML file itself when saved
- as sent to the DSP
I don't understand why, but it's how IL-DSP 1.0, firmware version 1.3 does it.

Assuming that the DSP internally uses an integer accumulator for each EQ band, with no headroom to prevent clipping then it's very easy to introduce digital clipping.
The solution then is to set all the EQ bands with negative gain as EQ10, EQ9, EQ8 etc: essentially, to setup the EQ backwards.
Further EQ bands with positive gain will process an input signal already lowered in gain.

When looking at the xml file saved when storing a preset, it is also recorded backwards: the EQ1 band becomes PEQ_1_10

So yeah, miniDSP @devteam has some work to do either to:
- fix the order and educate users on how to use EQ bands order to prevent clipping.
- if supported by the DSP hardware and not burning too much power: switch to floating point biquads instead of integer.
- calculate and apply an EQ input gain offset automatically which would just prevent the issue to happen altogether.

In the meantime, you can make your EQ backward, starting at EQ10 instead of EQ1.

Okay, so after posting my message, the thought occurred to me that there might have been some bug causing the issue.

The behavior here is different from other EQs - say, Equalizer APO, where the order of the filters is irrelevant. As long as the global curve is below 0 dB, Equalizer APO will not distort. And if the global curve does break the 0 dB limit, that fault condition is very clearly indicated in bright red.

Above 0 dB amplification in the digital domain is not something that can be silently ignored, ever. If that condition exists, at the very least make the user aware of it. Would be nice to also indicate by how many dB is the maximum amplitude exceeded. Best case scenario, automatically offset the input level within the DSP so as to lower the whole curve below 0 dB. This is the default behavior with a lot of great EQs and DSPs out there.

Looks like miniDSP has some work to do to prevent distortion - with the IL-DSP in particular, and with any DSP in general.

Thanks for the workaround.

supercurio wrote:

Unless... the bands were not sent in the right order, which is exactly what's happening.

There is a bug in the current version of IL-DSP plugin UI which for some reason inverts the band's order:
- in the XML file itself when saved
- as sent to the DSP
I don't understand why, but it's how IL-DSP 1.0, firmware version 1.3 does it.

Assuming that the DSP internally uses an integer accumulator for each EQ band, with no headroom to prevent clipping then it's very easy to introduce digital clipping.
The solution then is to set all the EQ bands with negative gain as EQ10, EQ9, EQ8 etc: essentially, to setup the EQ backwards.

I just want to add - if your findings are correct, then this is counter-intuitive behavior.

There's two possibilities here:

1. All that matters is the global EQ curve. If the global EQ curve is below 0 dB, then no distortion occurs..

2. Each individual filter matters, and they are applied sequentially. In that case, it is critical that the first filters must have negative gain.

In case #1, a simple global check would be enough. The plugin app could just check the global curve, and if any portion exceeds 0 dB, show some sort of warning. Better yet, reduce the input so as to keep the global curve below 0 dB.

In case #2, the vast majority of users would expect that the filters are applied in the order shown in the plugin app: filter 1 first, then filter 2, and so on. Reversing the actual order of the filters is a really nasty bug. Yes, in the back of my mind, I always had this doubt - do individual filters matter or not? If they do, I better put the negative gain filters first. But then you're saying the app reverses the order of the filters, and each individual filter matters. If true, this is a very deceptive bug: you try to do due diligence, but the app negates all that. It's almost like a trap.

I do acknowledge that figuring out the right user interaction is hard for a lot of engineers. Systems, software, and hardware are one thing; but people are a very different thing. Different mindsets are required to solve problems in these different realms.

I get occasional distortion even when I have only one filter, and it has negative gain. It's a high shelf filter with a Q factor of 0.7, so there should be no overshoot above 0 dB (like it happens with high Q filters).



If I reduce the digital volume below 100% it does not distort anymore - and it's a rare event anyway. But it should not distort with input at 100% when no filter has positive gain.

One possibility is when applying filters (even those not programmed to +db) the crest factor can change and cause some peaks to slightly exceed 0db. This is why your level adjustment to -1db alleviated the issue.

This is not an uncommon issue in DSP-based xovers/EQ's. I've seen it many times.

Dave.

If you read my post more carefully, you'll notice I've said the Q factor is 0.7. There is no overshoot with simple shelf filters at this Q level. Higher Qs, or more complex filters, sure, it will overshoot. But I kept things simple on purpose to avoid over-unity amplification.

I did read your post carefully. I'm telling you that there IS the possibility of above 0db peaks even with filters of Q=0.7 or less.
As I said (and let me repeat again) I've seen it many times.

Crest factor of the signal envelope changes and you can find yourself with peak levels slightly increased relative to no filter even though the average level might be reduced.. I know this seems counter-intuitive, but it is a known effect and easily tested for.

www.minidsp.com/forum/software-support/1...ing-or-control#38700

Dave.

Not with the filter I used.

Cheers!

How do you explain the fact that adding a -1db level shift solves your clipping problem?? Are you absolutely positive it's something in the programming implementation that you can blame miniDSP for??

I'm not making this stuff up. When I tell you something I either have academic and/or practical knowledge on the topic.
I don't have an actual IL-DSP to test directly, otherwise I could confirm it definitively. But I'm open to the possibility.......yet you reject it out of hand.

When you push right to the top of the window with these devices (with the right program material,) you can get into weird effects.
Are you familiar with the concept of inter-sample overs? It's not unrelated to this.

I suggest more objective thinking/testing and less speculation.

Cheers,

Dave.