[sdiy] Looking for cheap lowpass filter algorithm

[Eric Brombaugh]

Scott Gravenhorst wrote:
> Eric Brombaugh <ebrombaugh at earthlink.net> wrote:
>> Seb Francis wrote:
>>> With the Parks-McClellan Equiripple (aka Remez) algorithm it's possible 
>>> to get more stop band rejection at the expense of increased ripple.  It 
>>> seems the big disadvantage with the results this algorithm gives is that 
>>> the phase response within the passband is always oscillating between 
>>> -180 and 180 deg with every 'ripple' in the amplitude response.  This is 
>>> the case regardless of how many taps you use.
>> True enough. That's part of the reason that there are so many different 
>> ways to compute taps. PM / Remez happens to be a fairly simple way to 
>> specify the filter characteristics and get (reasonably) predictable 
>> results. Using Matlab & Octave you can try others as well, such as 
>> windowing, etc.
>>
>>> I tried quite a few different combinations of taps, ripple, stop band 
>>> rejection and listened to them as well as looking at the graphs.  In the 
>>> end I settled on one with 9 taps that sounded really nice to my ears.  
>> That's starting to blur the line between engineering and art: trading 
>> off the objective for the subjective. It's great to be able to do 
>> listening tests and find a filter characteristic that sounds good even 
>> though the hard evidence of the spectral response looks awful. When it 
>> uses fewer resources as well that's even better.
> 
> Well, this has been a very interesting thread for me as I'm interested in sticking my
> toe into the FPGA filter water very soon.  I had hoped that what you mentioned wouldn't
> be the case, that one could design a filter with math and be fairly sure the
> implementation would have an expected result.  What I see here is that isn't always the
> case.  

Yes, it's an unfortunate fact that there are lots of ways to design a 
digital filter and all of them involve trade offs. For example, the 
Parks-McClellan algorithm is iterative and doesn't always converge. 
Minor parameter tweaks can result in significant changes in the results. 
As Seb discovered, a filter that looks great on paper may not sound 
great and vice-versa.

> I'm concerned about resources since the Spartan-3E has an FPGA with 20
> multipliers (and not all of them can be used depending on what is done with block RAM),
> so even with 20 multipliers available, they will probably have to be multiplexed if the
> design uses more than one filter or becomes otherwise complex.  That's something I
> naively thought I could avoid. 

If you want to do brute-force filters with no resource sharing you're 
going to run out of hardware pretty quick. Bear in mind that the toggle 
rates on these FPGAs can easily exceed 200MHz, so dedicating 20 200MHz 
multipliers to an audio speed filter is what we in the business call 
"overkill". Designing your filter to use a couple block RAMS and a MAC 
will give you a lot more options.

> So what are your suggestions regarding filter design, assuming you know you want certain
> rolloff characteristics, phase distortion, ripple, etc., do you start with a low number
> of taps (how many?) and keep physically testing/increasing the calculated coefficients
> until the ear says "OK"?  

A bit of experience with the design tools and you'll be able to guess 
where to start given the characteristic you're after. From there though 
it's iteration all the way. Guess, check and repeat.

> I guess what I'm asking is given all this, what good is the graph then?  How truthful is
> it, i.e., on what graphical characteristics can I depend to give me reliable and useful
> information about my prospective design?

The graph is telling you only a few aspects of what the filter does 
(phase & magnitude response). This is sufficient for many applications, 
such as RF/IF filter design. For audio though, the final transducer is 
in your head and that's the only measurement that really counts.

Eric