Re: [Discuss-gnuradio] FIR filter 'filterN' method

[Eric Blossom]

On Mon, Jul 03, 2006 at 01:50:11PM -0700, Johnathan Corgan wrote:
> I'm designing an adaptive FIR filter base class.
> 
> In the guts of all the current FIR filter types, there are filterN and
> filterNdec methods that compute multiple outputs as a batch.  These are
> called in the ::work method of the calling signal processing block:
> 
>   ...
> 
>   if (decimation() == 1)
>     d_fir->filterN (out, in, noutput_items);
> 
>   else
>     d_fir->filterNdec (out, in, noutput_items, decimation());
> 
>   ...
> 
> As far as I can tell, in all the various types, these are implemented
> identically as simple loops calling the 'filter' method to calculate
> single outputs iteratively:
> 
> ...
> void
> gr_fir_ccf_generic::filterN (gr_complex output[],
>                            const gr_complex input[],
>                            unsigned long n)
> {
>   for (unsigned i = 0; i < n; i++)
>     output[i] = filter (&input[i]);
> }
> ...
> 
> In an adaptive filter, the class needs to update the filter taps after
> each output sample. So I'd like to call 'filter' directly in my own loop
> in my ::work function, followed by a call to update_weights during the
> same loop iteration.

OK.  

The filterN{,dec} function was defined to allow for possible
future optimization.

> Is there any reason not to do it this way? Since all the existing
> filterN functions are implemented as this simple loop, can I just do the
> same thing myself in my ::work function instead? Will there ever be
> additional stuff implemented in filterN in some FIR class that won't
> ever get called because I'm bypassing it to do myself?

Yes, we could be adding stuff in the future.

A bigger issue however, is that setting/adjusting the taps on the SIMD
versions is fairly expensive.  If your filter is always adapting,
you'll probably want to reimplement it in terms of the generic FIR
code, bypassing the SIMD speedups.

Eric