1
$\begingroup$

I have to embed a bandpass filter into a software application.

All the signal processing will be done in 32 or 64-bit double precision.

The filter coefficients for an IIR Butterworth filter are computed offline in Matlab.

  • What is the best way to implement the filter in the application?

Right now my plan is to implement the filter as cascaded second order sections in transposed direct form II, but I have no practical experience (and literature on the practical part of implementation is also kind of sparse), so I'm just kind of guessing.

For example: Second order sections are used to avoid numerical problems, but do I really need to take care of that when the processing is done in floating point precision, also which form should i chose for the realization of the filter?

I would be thankful for any tips or literature hints.

$\endgroup$

2 Answers 2

2
$\begingroup$

If your filter is not of insane order, than double precision (64bit on most machines) floating point will totally suffice, and you really shouldn't worry too much. I agree with Arnfinn here.

I don't 100% agree on the optimization recommendation – in fact, if you want my two cents on general purpose CPU-based software implementations of filters, then simply don't use IIRs; they might be shorter than FIRs with the same flatness/transition band steepness/suppression, but the fact that they are recursive makes them a whole lot harder to execute fast, not to mention that shortcuts like polyphased decomposition don't generally work, and thus, you can't save as much CPU when e.g. building a decimating anti-aliasing filter.

My honest advise is:

  1. Don't worry too much about CPU performance. If you're not trying to do this in JavaScript, and you got but a couple of kilosamples to second to worry about, a simple filter implementation will do.
  2. If you're worried about numerical accuracy, don't worry more than at the level that's sensible: unless your filter is multiple thousand taps long or your taps are extremely bad-behaved, a FIR won't really hurt much. If you're worried about stability, simply don't use an IIR.
  3. Don't reinvent the wheel if you don't have to. There's excellent optimized DSP libraries out there, and as long as the programming language you use supports native libraries with a C calling convention ABI (it probably does), you can use most of them. Just let whatever tool you chose provide the taps for your IIR or FIR, and that library will do its job. I personally like libVOLK a lot, but it concentrates on FIRs, for the reasons given above.

Generally: You're asking about numerical accuracy without indicating which boundaries you need to work in and what filter orders you're talking about. This might indicate that you're not really having any problem at all, because otherwise, you might have noticed already that these are the critical aspects here :)

$\endgroup$
8
  • $\begingroup$ thank you for your answer. It's like you guessed it, the implementation has to be in JavaScript. :) Are you implying that i have to take special care about performance here? To give a little more information: I'm implementing a bank of band pass filters for audio signals (maximum length of 10 sec) with orders ranging from 6 to 12. I left out designing FIR filters because the filters have to comply to certain standards set by the "Deutsches Institut für Normung" and according to literature it's very hard to design FIR filters compliant to those standards, but maybe I will try it. $\endgroup$
    – user967493
    Commented Nov 21, 2016 at 12:19
  • $\begingroup$ JavaScript is really the popular language least suitable for DSP, IMHO. No libraries, no support for vector operations, stupid standard lib. Seriously. If you can, use something else. Of course, if you don't have a choice regarding the filter type, well, you'll have to implement that specific filter. And: if you really must do this in JavaScript, then ... have fun. If your IIR happens to be implementable as biquads, use the webaudio biquad API. If that's not possible, then it really doesn't matter what type of implementation… $\endgroup$ Commented Nov 21, 2016 at 12:24
  • $\begingroup$ … you choose. the fact that you're executing JS will outweigh the computational load of a 62-tap filter by orders of magnitudes, anyway. Good news is that for 62 tap audio filters, I don't think you need to worry the least about numerical accuracy. $\endgroup$ Commented Nov 21, 2016 at 12:25
  • $\begingroup$ :) Thank you again. Having to use JavaScript is infact a pity. I'm not quite sure if I can use the web audio api because of some compatibility issues, so to be safe I'm writing my own. By the way, there is a math library called mathjs, that does vector math: link $\endgroup$
    – user967493
    Commented Nov 21, 2016 at 12:39
  • $\begingroup$ Yes, but it's a JavaScript library, and that means that although it gives you some vector API, unlike in "proper" programming languages, there's no support for vectors in the runtime – i.e. if you calculate for example the dot product between two vectors, it's still going to be a slow for loop over every pair of numbers, instead of letting your processor do eg. four multiply-add at once, on values that are adjacent in memory. And the fact that there's no chance to instead of doing a slow JS for loop let a native library handle this is what's killing your performance. … $\endgroup$ Commented Nov 21, 2016 at 12:44
0
$\begingroup$

I'm sure people will have lots of opinions about this subject. I've never had any problems implementing filters with floating point numbers, even direct form I. If you are worried and can handle a bit more computational load, use a direct state-space implementation and a balanced realization. See 'help balreal' in MATLAB.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.