I just chased a test failure that one of our dsp code unit tests flagged up after extending the range of some oversampling test cases a bit. It came down to the fact that this call will return an Array of coefficients with the size of 0 for
auto cutOffFreq = 21609.0f;
auto sampleRate = 705600.0;
auto coeffCascade = juce::dsp::FilterDesign<float>::designIIRLowpassHighOrderChebyshev1Method (cutOffFreq, sampleRate, 0.1f, -0.1f, -90.0f);
jassert (coeffCascade.size > 0); // << fails
Tbh. filter design algorithms are not my main topic, so stepping through the filter design code only revealed that the parameter
N which determines the number of coefficients returned is 0 – but I don’t see something obviously wrong
Is there some DSP guru out here that can spot an obvious reason why the set of parameters chosen here cannot work? In that case an assertion in the filter design methods pointing would be really helpful. Otherwise I assume this is some kind of bug caused by e.g. rounding errors?
I suppose the problem is that
fp becomes negative, as the transition width you specify is wider than the normalized cut off frequency (21609.0f / 705600.0 = 0.030625) and the transition width is set to 0.1f (which becomes 0.05f when / 2). You might want to lower that one in the call to
The design function could need two assertions, fp > 0.0f and fs < 0.5f.
Does this solve the issue? Or do even small fp values greater than 0 cause N = 1?
Thank you for that quick response. Yes that helps! I actually didn’t question the fixed values specified in that piece of code, but they seem to be the actual underlying error – changing the width solves the issue.
Would have probably saved me a lot of work to find the source of the error. So +1 from me for adding some assertions to the design methods.
I also wonder if it should be documented that this method might return an empty array under some circumstances.
Thanks for your patience. I’ve added some assertions to this function, so hopefully these kinds of errors will be more obvious in the future: