Performance of IIR filters on silence

[geoffw64]

Hi Dan & team,

I've got an issue with performance of IIR filters when processing silence. I've done hours of troubleshooting but haven't been able to find the root cause.

Application: Audio DSP
Environment:
KFR 6.0.3 avx2 64-bit (clang-15.0.0/macos) +in +ve
MacOS running Sonoma; Core Audio
JRiver

Symptom: Processing audio (sound) works fine and performs very well. When I stop playback in JRiver, my app continues receiving buffers from CoreAudio and the samples are all zero values, as expected. At this time, CPU usage of my app and the elapsed time to process samples increase by roughly an order of magnitude.

Troubleshooting: The issue occurs when processing sample sets with all zero values (silence). I use IIR filters to perform bass management and room correction. Both suffer the performance problem.

My bass management implementation (also see #245):

Filter definitions (performed only once during setup):
uint8_t const filter_order = 2;
// Low pass filters; two are used in series
zpk const lp_zpk = iir_lowpass(butterworth(filter_order), frequency, sample_rate);
iir_params const lp_params = to_sos(lp_zpk);
iir_filter const lp_filter_1(lp_params);
iir_filter const lp_filter_2(lp_params);
// High pass filters; two are used in series
zpk const hp_zpk = iir_highpass(butterworth(filter_order), frequency, sample_rate);
iir_params const hp_params = to_sos(hp_zpk);
iir_filter const hp_filter_1(hp_params);
iir_filter const hp_filter_2(hp_params);

My sample_rate is 96000

Filter application (performed on every sample set):
// Apply 2nd order low pass filter twice to produce LF samples
lp_filter_1.apply(lf);
lp_filter_2.apply(lf);
// Apply 2nd order high pass filter twice to produce HF samples
hp_filter_1.apply(input);
hp_filter_2.apply(input);

"lf" and "input" parameters are declared as univector
The filters process up to 2048 samples on each pass.

Again, these filters perform very well with actual sound. The performance is only poor on silence.

Is my implementation sensible or is there an issue in the KFR implementation?

I can also post details of the room correction filters if that would help.

Thanks in advance,
Geoff.

[dancasarin]

Hi,
You likely encountered the classic denormals problem. When a filter is fed with zeros, the filter's delay line can produce very small values known as denormals. These denormals can significantly degrade floating-point performance.
If you can tolerate negligible precision loss, you can configure the CPU to flush denormals to zero. This restores high performance for all floating-point operations within the IIR filter.
This issue is not related to KFR or how you use KFR and may happen with any code that produces very small numbers.

You can use an RAII helper to set CPU flags during audio processing:

struct fp_mode_scope {
    fp_mode_scope() noexcept : csr(_mm_getcsr()) {
        _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
        _MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON);
    }
    ~fp_mode_scope() noexcept {
        _mm_setcsr(csr);
    }
    fp_mode_scope(const fp_mode_scope&) noexcept = delete;
    fp_mode_scope& operator=(const fp_mode_scope&) noexcept = delete;
    uint32_t csr;
};

void process_audio() {
    fp_mode_scope fp_scope;
    // processing...
}

[geoffw64]

Hi Dan,

Yep, that was the root cause! Thanks for your prompt response and solution.
The loss of precision for such tiny values is not significant in my application.

I appreciate your help.

Best,
Geoff.

Here is a couple of Intel's explanatory notes that may assist others who encounter the issue:
https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2023-0/denormal-numbers.html
https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2023-0/set-the-ftz-and-daz-flags.html

[geoffw64]

Answered by Dan above