Audio Equalizer using FIR

Status
Not open for further replies.
While 65k taps is a common number for audiophile convolution based equalization, perhaps someone could talk about the audible effects of going down to something the teensy4 could handle. Looking at the input correction file, I see nothing after about 30 msec.
 
So, for the Audio Equalizer by Bob Larkin and in general for your OpenAudioLib, it would be very handy to have a FIR convolution filter block (well, maybe two: one real and one complex) in order to substitute the standard FIR filtering with convolution filtering.

I'm a bit confused by your statement "in order to substitute the standard FIR filtering with convolution filtering". When convolution is done in the time domain, convolution *is* FIR filtering, right? How is convolution filtering different than an FIR?

[Alternatively, one can choose to do convolution in the frequency domain, but that's not what we're talking about here.]

Clearly, I'm missing what you mean by "convolution filtering"?

Chip
 
The basic finite digital signal processing operations are convolution, correlation, DFT. DFT maps convolution to multiplication, and
vice-versa. FIR is convolution in the time-domain (thus multiplication in the frequency domain). IIR filters convolve input and past
outputs which gets more convoluted :) - and is no longer finite (and can be unstable/metastable). Convolution is correlation with
one signal reversed. Of course there's more to it, but yes, FIR is simple convolution.

convolution/correlation are O(N^2),
DFT is O(N log N)
multiplication is O(N)

So convolution for lots of points is faster by cutting into blocks, FFT->multiply->IFFT, and stitching back together. Numerically the errors
will propagate differently so some care is needed with representation accuracy.
 
@jonr: not sure about your statement on the "correction file, which contains nothing after 30msec": could you explain which file you mean and what is lacking after 30msec? It seems I did not get the point of your statement. EDIT: After re-reading I think now I understand: your room correction file does not contain any more correcting coeffs after about 30msec, is that right? The I would assume that the T4 could easily handle that, because that is only 1440 taps @48ksps. You could use a 2048 tap or 4096 tap FIR and always be on the safe side.

@chipaudette: What I mean is "Fast Convolution Filtering", which is FFT, subsequent complex multiplication of the magnitude and phase values with FIR coeffs and inverse FFT, leading to exactly the same result as FIR in the time domain
And Fast Convolution Filtering is much more efficient in terms of CPU power than FIR filtering in the time domain and that holds for filters above about 60 filter taps
reference is here: https://pdfs.semanticscholar.org/9f10/d8c9237f1c383862225dec0d715c6f63961c.pdf
 
Yes, the impulse response of the speaker system is measured, this impulse is processed into a "correction impulse", then music is convolved with the correction impulse to get flat speaker response. While the measured impulse response has a long tail (say to 1.5 seconds), the correction impulse looks to be < 30 msec. And indeed, a quick listening test indicates that far fewer taps (eg, 4096) sounds fine. I also see that commercial products like OpenDRC use fewer taps (eg, 6144 taps).

BruteFIR can partition for reduced latency. This plus fewer taps makes real-time use acceptable.

Summary: yes, I think a teensy 4 with s/pdif in and out could provide digital room correction, comparing well with OpenDRC.
 
@chipaudette: What I mean is "Fast Convolution Filtering", which is FFT, subsequent complex multiplication of the magnitude and phase values with FIR coeffs and inverse FFT, leading to exactly the same result as FIR in the time domain
And Fast Convolution Filtering is much more efficient in terms of CPU power than FIR filtering in the time domain and that holds for filters above about 60 filter taps
reference is here: https://pdfs.semanticscholar.org/9f10/d8c9237f1c383862225dec0d715c6f63961c.pdf

Oh, so we *are* talking about frequency domain processing. When I measured FFT vs FIR based processing on the T3.6 using the ARM CMSIS Float32 library, FIRs are more efficient up to around 96 points. By the time you get to 128 points, I think that the FFT-IFFT is more efficient. This assumes 50% overlap for the FFTs. This assumes no zero-padding of the FFTs. That's my experience.

My testing of FFT and IFFT on the T3.6 is written up here: http://openaudio.blogspot.com/2016/10/benchmarking-teensy-36-is-fast.html

Sadly, I only tested relatively short FFTs (only up to 512 points).

Chip
 

Attachments

  • Table%u00252Bof%u00252BMax%u00252BSample%u00252BRate.jpg
    Table%u00252Bof%u00252BMax%u00252BSample%u00252BRate.jpg
    67.6 KB · Views: 92
I'm still struggling to find a solution (and understand - I've never used teensy audio).

Ideal for me would be SPDIF input and output plus teensy4 software performing convolution (say 8192 taps, could be "fast convolution"). Not clear if this exists in a ready to use form.

Next best would be SPDIF input and output plus parametric equalization - say 5+ bands, being able to specify freq, gain and Q for each band. This works well because it is the way REW (room equalization wizard) outputs its automated speaker correction equalization.
 
I looked at and compiled DD4WH's fast convolution code (but didn't listen). Seems like the way to go. Convolution provides for *any* linear time invariant effect - equalization, reverb, etc. Or any combination of such effects.
 
For the record, I modified DD4WH's fast convolution code and it works great. 2 channels, 12288 taps each. This many taps provides good low frequency resolution. Still using REW to measure and DRC (Denis Sbragion) to produce a speaker correction.
 
Status
Not open for further replies.
Back
Top