[sdiy] Looking for cheap lowpass filter algorithm

[Magnus Danielson]

From: Seb Francis <seb at burnit.co.uk>
Subject: Re: [sdiy] Looking for cheap lowpass filter algorithm
Date: Thu, 17 Aug 2006 11:20:23 +0100
Message-ID: <44E442E7.7030901 at burnit.co.uk>

Hi Seb,

> Magnus Danielson wrote:
> > Look at it this way: You could do 32 multiplies at 48 kHz, it is just that your
> > sampling of every other sample on the output of that FIR filter will actually
> > waste half of the processed samples and thus half of your total amount of
> > filtering computation. By letting two samples pass between each computation
> > rather than one, you have integrated the sampling somewhat with the filtering.
> > This would be equalent but only half the processing. Neat huh?
> >
> >   
> 
> Sounds good.  I just wondered if there was anything to be gained (other 
> than wasted CPU cycles) in using all the 48kHz input data in the filter, 
> but I guess not.

You *ARE* using all the 48 kHz input-data, not just all of the 48 kHz output
data of the filter. Every odd sample will only go through the odd taps of the
filter while every even sample will only go through the ever taps of the
filter, where as normally all samples will go through all taps of the filter.

> >> And the other thing I'm still getting my head around is how to calculate 
> >> the optimal coefficients for my application - which requires a very 
> >> steep response filter with the stopband at 0.25*Fs (or possibly at 
> >> 0.5*Fs depending on the answer to the above question).
> >>     
> >
> > Fs/4 is your answer regardless.
> >   
> 
> I was referring to the fact that by feeding only every other sample into 
> the filter, then the Fs is effectively 24kHz which means that I need to 
> design the filter coefficients with stopband at Fs/2.  Right??

Nonono... you are still doing the filtering in the 48 kHz domain, because you
need to anti-aliasing the data *BEFORE* the sampling. The computational trick
doesn't change that, it mearly reduces the amount of computing needed to be
done to achieve the equalent thing, but your processing is still in the 48 kHz
sampling rate, but only the inte 24 kHz processing rate.

> > The Parks-McClellan/Remez-exchange should do what you want, you just need to
> > learn to twist the knobs a bit.
> 
> Thanks.  The Java applet for calculating this one was a bit buggy and 
> didn't always give a result for all parameter settings (so I couldn't 
> quite get it how I wanted it).  I've now found a better applet here:
> http://www.nauticom.net/www/jdtaft/lopassE.htm

OK.

Cheers,
Magnus