Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 34 of 34

Thread: Audio Equalizer using FIR

  1. #26
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    997
    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.

  2. #27
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    301
    Quote Originally Posted by DD4WH View Post
    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

  3. #28
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,110
    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.

  4. #29
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    657
    @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/9f1...5c6f63961c.pdf

  5. #30
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    997
    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.

  6. #31
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    301
    Quote Originally Posted by DD4WH View Post
    @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/9f1...5c6f63961c.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/1...6-is-fast.html

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

    Chip
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Table%u00252Bof%u00252BMax%u00252BSample%u00252BRate.jpg 
Views:	37 
Size:	67.6 KB 
ID:	20961  

  7. #32
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    997
    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.

  8. #33
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    997
    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.

  9. #34
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    997
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •