some practical advice need on FIR filtering

[CharlieLaub]

I've done a bunch of projects using IIR digital filters to implement multi-way loudspeaker crossovers. Now I would like to investigate the possibility of using IIR filters for the same.

I'm familiar with the general concept of FIR filters, but have absolutely no clue about the practical simultaneous implementation of multiple FIR filters that would be necessary to pull off a complex multi-way loudspeaker crossover. So I thought I would throw out some questions here and ask people to chime in with their thoughts and experiences.

I'm envisioning a small computer at each loudspeaker processing an incoming signal using FIR filters. There might be 10 or more filters that need to be computed simultaneously from, for instance, a 96kHz spdif stream. What kind of computing power would be needed? Let's say this is done in Linux on a Raspberry Pi - is this platform up to the task? What about an Intel NUC with a Celeron processor, or even an i3 or i5? How much computing power is necessary to pull this off?

If people are using FIR filtering out their for crossovers, what hardware are you using?

What software should I look into for calculating FIR filters? I see there is the rePhase tool that has a thread here. There are several FIR tools listed on the miniDSP web site here:
FIR Filter tools
For someone starting out, any recommendations?

I wrote a set of software tools for designing crossovers from measurements (ACD, the Active Crossover Designer). I originally wrote these to generate IIR filter biquad coefficients for miniDSP or other IIR filtering hardware. I'd be interested in seeing if I could also generate the FIR version of the IIR filters as well, so that the user could implement the crossover using either IIR or FIR depending on what they need. The ACD tools use only worksheet functions - would it be possible to build in the FIR filter calcs that way, or is that too complicated and I will have to use VBA or simply refer the user to an external tool to calculate the FIR filters?

Well, that's it for a start. Please help me get up to speed with FIR filtering!

 

[CharlieLaub]

nobody has anything to say about FIR filtering?

Maybe I should have posted in the PC Based forum...

 

[jcx]

general purpose processor chips may have DSP instructions optimized for FIR - but operating systems can get in the way of real time

BruteFIR users may know practical limits on Linux processors

most audio processors use dedicated DSP chips from AD or TI with even more optimization and no interfering OS
FPGA are used too

and GPU cards give ridiculous processing power if your problem fits the architecture

http://dafx10.iem.at/papers/WefersBerg_DAFx10_P76.pdf

 

[counter culture]

This is all about bit-depth, sample rate and number of operations between samples, so that is how you figure out what you can do.

Different architectures offer the opportunity for specialist processing, but the first option you're looking at is a C program that gets in a 16-bit, does it's thing (every time the same loop) and spits out a 16-bit before or just as the next sample arrives. You'll have 2 matrices, one holding the coefficients, the other holding as many samples as the filter requires, a FIFO.

Now you have to count or calculate the number of machine operations in your code, the processor clock speed will then tell you how long it takes to execute.

Maybe you're doing it on a PC, maybe it's assembler on a DSPic, maybe it's pipelined in VHDL in an FPGA. There's also the question of integer or floating-point. There are some math and coding tricks, e.g. exploiting symmetry, but that's the basics.

 

[CharlieLaub]

I read through the BruteFIR web page and found this, which is the kind info I was hoping to get here:

How high throughput can I get?
With a massive convolution configuration file setting up BruteFIR to run 26 filters, each 131072 taps long, each connected to its own input and output (that is 26 inputs and outputs), meaning a total of 3407872 filter taps, a 1 GHz AMD Athlon with 266 MHz DDR RAM gets about 90% processor load, and can successfully run it in real time. The sample rate was 44.1 kHz, BruteFIR was compiled with 32 bit floating point precision, and the I/O delay was set to 375 ms. The sound card used was an RME Audio Hammerfall.

And this:

Hardware considerations
Note: the hardware referenced here is a bit dated (a long time ago the text was written), but apart from that, the text is up to date.

What is important for BruteFIR is that the machine has fast memory and fast processor. A Pentium 4 with its RDRAM is probably the best choice today. However, an Athlon with DDR RAM is not bad either, and significantly cheaper. A fast processor on a computer with slow memory is what most often causes disappointment. For example, a dual Pentium III at 1 GHz with good use of both processors was found to be slower than a single processor 1 GHz AMD Athlon with DDR RAM. The problem was that the Pentium III had poor memory performance. The stream benchmark [20] is a good program to use to verify the memory bandwidth if you think you get poor BruteFIR performance.

If you use SDRAM you will never get exceptional memory bandwidth, however, some tuning of timer settings in the BIOS, or overclocking of the memory bus can give you quite decent performance.

When it comes to sound hardware, you should be able to use any card that is compatible with ALSA [2]. However, it is not very likely that the sound card code of BruteFIR will work for all sound cards supported by ALSA, although that is the goal. If you get problems with your sound card, please send me a mail, and I will do my best to get it to work, or even better, try to get it to work yourself and send me a patch.

The best sound cards are those which support partition sizes which are a powers of two. If that is not the case, BruteFIR must run in input poll mode, which is not necessarily less reliable, but will consume a part of the spare processor time.

The worst possible sound card is one which does not support partition sizes with a power of two, and can only transfer large sample blocks at a time. Then BruteFIR will run unreliably or not at all.

If you want to avoid problems I recommend RME Audio [21] Hammerfall (Light) (RME9652 and RME9636) and also cards from the RME Audio Digi96 series (RME96), since those are the cards I use myself. The Hammerfall cards support up to 26 inputs and 26 outputs, the Digi96 cards support up to 8 channels. They are not the cheapest cards out there, but these are clean professional cards, fully digital with ADAT and S/PDIF inputs and outputs, which means you can have high-quality DACs and ADCs outside the computer to get the best sonic performance possible.

The Hammerfall cards allow for shorter delay (minimum partition size is 64 samples) than the Digi96 series (minimum size 1024 samples).

So it looks like its' do-able with a fast enough processor for multiple simultaneous filters, even with a lot of coefficients per filter.

 

[scott wurcer]

From the Sorceforge VST convolver page.

Performance is excellent, possibly the best available under Windows, and subject continual improvement. A stereo 65536-tap filter, the largest that makes sense when applied to a 44.1kHz source, executes at 40 times real time, representing a 3% cpu hit, on a 3.4GHz Pentium 4. Even on a 300MHz Pentium II, the reported cpu hit is about 30% when convolving with such a filter. So your old machine can be put to good use. Mixing channels results in some slowdown (six 65536-tap filters will consume less than 10% cpu on a 3.4GHz Pentium 4).