I'm interested in implementing EQ and digital crossovers on the PC. I'm a programmer but in this case I'm not trying to right code just grasp the basics enough to use existing packages. I've read a little bit about FIR filters but some things are still fuzzy for me.
It seems like the "windows" referred to related to FIR filters (Kaiser, Hamming etc... ) are approaches to "designing" FIR filters which means creating coefficients to use with a FIR filter execution engine. So they related to the "design" stage of FIR filters and but aren't part of the algorithms used for the implementation a FIR filter execution engine. On the execution engine side a "window" is also referred to but this is just a sample buffer not some specific algorithm like the above. At least this is what I have gathered. However, in reading the Brutefir page http://www.ludd.luth.se/~torger/brutefir.html I see it mentions using a Kaiser window for doing "subsample delay" and you can set the "beta" to be used. Since Brutefir is just a FIR filter execution engine this makes me think I'm wrong and the different window types are part of the algorithms for the execution engine?
Also I haven't found anything like a practical how to for developing FIR filters for doing crossovers in speakers or the like. I mean anything saying this window type is better for crossovers of this slope in this circumstance or how many coefficients is usually sufficient to get suitable audio quality etc. Does anything like this exist? Or maybe the tradeoffs involved are too complicated to make a simple cookbook for stuff like this?
It seems like the "windows" referred to related to FIR filters (Kaiser, Hamming etc... ) are approaches to "designing" FIR filters which means creating coefficients to use with a FIR filter execution engine. So they related to the "design" stage of FIR filters and but aren't part of the algorithms used for the implementation a FIR filter execution engine. On the execution engine side a "window" is also referred to but this is just a sample buffer not some specific algorithm like the above. At least this is what I have gathered. However, in reading the Brutefir page http://www.ludd.luth.se/~torger/brutefir.html I see it mentions using a Kaiser window for doing "subsample delay" and you can set the "beta" to be used. Since Brutefir is just a FIR filter execution engine this makes me think I'm wrong and the different window types are part of the algorithms for the execution engine?
Also I haven't found anything like a practical how to for developing FIR filters for doing crossovers in speakers or the like. I mean anything saying this window type is better for crossovers of this slope in this circumstance or how many coefficients is usually sufficient to get suitable audio quality etc. Does anything like this exist? Or maybe the tradeoffs involved are too complicated to make a simple cookbook for stuff like this?
jrwone0,
You're pretty much right on the money with your post. Some points:
- Windowing is indeed to do with coefficient design. A popular method of designing a filter is to begin with the central chunk of a sinc function as the filter kernel and then taper it at the ends with some windowing function. Without windowing, if you stacked multiple copies of your kernel end to end, there would be a sharp transition between each one. The aim of windowing is to mitigate this and get a smooth transition - something which (not immediately obviously) has a huge effect on the performance of the filter.
Once the coefficients are designed, all you need is a convolver to perform the filtering - you don't need to consider things like windowing again.
- BruteFIR is a comprehensive FIR filtering system - not just a convolver. The subsample delay (which is implemented with another convolution process) is an optional feature which is not part of a basic, general FIR filter, but which the author of BruteFIR thought would be useful to people who need one. In general speaker applications, I imagine sub-sample delay would not often be needed.
- There are some guides around on the net which take you through the basic properties of different window functions (and the maths of them generally isn't too bad, if that's your thing), but overall cookbooks are, as you say, difficult come by. I would suggest that, no matter how many guides you can find around, nothing will beat manual experimentation with a numerical software package. I believe GNU/Octave runs on Windows as well as Linux, and is free (unlike MATLAB, which is what I've been using since my undergrad). It will certainly take some learning if you've never used such a package before, but will allow some real fine-tuning of both your filters and your knowledge. IMO, the variables are really a bit subtle to allow cookbook style design for this sort of thing.
You're pretty much right on the money with your post. Some points:
- Windowing is indeed to do with coefficient design. A popular method of designing a filter is to begin with the central chunk of a sinc function as the filter kernel and then taper it at the ends with some windowing function. Without windowing, if you stacked multiple copies of your kernel end to end, there would be a sharp transition between each one. The aim of windowing is to mitigate this and get a smooth transition - something which (not immediately obviously) has a huge effect on the performance of the filter.
Once the coefficients are designed, all you need is a convolver to perform the filtering - you don't need to consider things like windowing again.
- BruteFIR is a comprehensive FIR filtering system - not just a convolver. The subsample delay (which is implemented with another convolution process) is an optional feature which is not part of a basic, general FIR filter, but which the author of BruteFIR thought would be useful to people who need one. In general speaker applications, I imagine sub-sample delay would not often be needed.
- There are some guides around on the net which take you through the basic properties of different window functions (and the maths of them generally isn't too bad, if that's your thing), but overall cookbooks are, as you say, difficult come by. I would suggest that, no matter how many guides you can find around, nothing will beat manual experimentation with a numerical software package. I believe GNU/Octave runs on Windows as well as Linux, and is free (unlike MATLAB, which is what I've been using since my undergrad). It will certainly take some learning if you've never used such a package before, but will allow some real fine-tuning of both your filters and your knowledge. IMO, the variables are really a bit subtle to allow cookbook style design for this sort of thing.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.