FIR Filter: 2026 Specs and Tradeoffs

What a FIR Filter Actually Does (and How It Differs From IIR)

A FIR filter performs a weighted sum of the current sample and a fixed number of past samples. No feedback path. So it stays stable no matter what input arrives.

The convolution equation boils down to y[n] equals the sum of h[k] times x[n minus k] for k from zero to N minus one. Each output point is literally a sliding dot product across a buffer of past inputs. It's basically a weighted average that shifts one sample at a time, and the math stays predictable enough that engineers drop these into audio chains and radar receivers without losing sleep over it.

The Convolution Sum: What Happens at Every Sample

You load the coefficients once. Then every new sample shifts the buffer and multiplies each tap against its corresponding delayed value before adding them up. A 256 tap filter therefore touches 256 values per output sample.

According to the EG3.com DSP Knowledge Pack the group delay equals (N minus 1) divided by 2 samples. For that 256 tap example you get exactly 127.5 samples of delay. It never changes with frequency. That predictability matters when you align multiple microphone channels or keep phase relationships intact in beamforming arrays. Smart speakers typically use 4 to 7 microphones for beamforming and every extra sample of mismatched delay hurts the nulls you are trying to create.

I keep a TMS320C54x dev board on the bench from an old VoIP project. The thing is, it's showing exactly how many MAC operations pile up once you move beyond textbook diagrams.

Linear Phase vs. Recursive Feedback: The Core Tradeoff

An IIR filter adds feedback so a single impulse can echo forever inside the structure. That's what gives sharp rolloff with far fewer operations. The Butterworth filter rolloff sits around 20 dB per decade per order according to the EG3.com DSP Knowledge Pack. You reach 60 dB attenuation with roughly three poles instead of hundreds of FIR taps. That's a meaningful difference in compute budget.

But the phase response bends all over the place. Group delay varies with frequency so a crisp snare hit smears across time in ways your ear notices immediately. FIR filters avoid that completely. Linear phase is the payoff and it is worth the extra compute in most professional audio work. Goodreads lists Adaptive Filter Theory by Simon Haykin at 4.18 out of 5 which tells you plenty of engineers still reach for the math when the linear phase requirement shows up.

If I'm being honest, half the time I open a new camera NVR I have no idea whether the vendor used FIR or IIR for the noise gate until I watch latency on an oscilloscope. The difference is audible before it is measurable.

Tap Count, Transition Bandwidth, and the Fred Harris Rule of Thumb

What tap count do you actually need before the filter stops fitting on your chip?

How Many Taps Do You Actually Need?

For 60 dB stopband attenuation and a transition band of Fs divided by 100 the Fred Harris rule of thumb calls for approximately 600 FIR taps. That is not marketing fluff. It is the ugly math that shows up the moment you tighten both passband ripple and stopband rejection at the same time.

A narrower transition eats taps fast. So does deeper attenuation. Texas Instruments built the TMS320C6416 around a C64x fixed point core that runs up to 720 MHz with McBSP and PCI and VCP TCP blocks. Even at that speed 600 taps per sample starts to crowd out the rest of your algorithm if you are doing anything else like beamforming or ANC in the same pass.

The FPGA crowd laughs here. A 256 tap FIR filter on a traditional DSP requires 256 clock cycles. On an FPGA with cascaded DSP48 slices it executes in a single clock cycle.

Worth knowing the difference before you pick your platform. It's a small thing, but it'll save you headaches later.

Stopband Attenuation vs. Filter Length: The Ugly Math

More taps deliver sharper skirts. There is no free lunch. Each extra tap burns memory for coefficients, cycles for the multiply accumulate, and power in the MAC units.

The Butterworth comparison makes the tradeoff obvious. Its 20 dB per decade per order slope looks gentle next to a 600 tap FIR that can drop 60 dB inside a few hundred hertz of the cutoff. Yet the FIR pays for that cliff with latency and compute. In low power wake word detection the filter must run below one milliwatt or it drains the battery before the main processor wakes up.

I have watched firmware teams cut tap count from 512 down to 128 just to stay inside the MCU flash budget. The response got uglier but the product shipped. Sometimes that is the right call.

FIR Filter Design Methods: Window Functions vs. Parks-McClellan

Your prototype works in MATLAB but the embedded target only speaks fixed point. Now what.

Window Method: Fast to Code, Suboptimal by Design

Take your ideal brick wall frequency response, inverse FFT it to get the sinc function, then multiply by a Hamming or Blackman window to truncate it. Done in minutes. The ARM open source CMSIS DSP library version 1.16.2 from 2025 ships 60 plus optimized filter functions including FIR up to q31 f32 and f64 with Helium MVE vectorized paths that deliver 2 to 4 times speedup over scalar C on Cortex M55 and M85 according to the ARM software CMSIS DSP GitHub Repository.

It is fast to code. The stopband ripples are not equalized so you waste taps where the error does not matter as much. Good enough for many microphone arrays but not when every decibel counts.

MATLAB costs around 2000 dollars plus 1000 dollars per toolbox for a commercial license. That's a real barrier. It still pushes teams toward Python alternatives until they need the filter design toolbox, and at that point the math on switching gets complicated fast.

Parks-McClellan (Remez): Optimal Equiripple and Why It Wins

This algorithm minimizes the maximum error across passband and stopband simultaneously. The resulting equiripple design uses every tap efficiently. Professional audio products that ship with ADSP SC589 processors usually land here because the SHARC plus cores and hardware accelerators chew through the coefficients without breaking a sweat.

You pay with design time and more complex code. The reward is fewer total taps for the same specification or deeper attenuation inside the same tap budget.

Coefficient Quantization: What Happens When You Go Fixed-Point

Float coefficients from your design tool get rounded to Q15 or Q31 on the target. That truncation moves your actual poles and zeros. The frequency response shifts a few hertz and the stopband floor rises. On a 16 bit ADC you already have 65,536 quantization levels before the filter even touches the data. Losing a couple bits in the coefficients can erase the advantage of that resolution in the stopband.

The TMS320 DSP family appeared on April 8 1983. We still fight the same quantization demons today. FPGA implementations dodge some of it with wider internal accumulators but the final output width still bites.

Dave's Take

Dave's Take: Josh cites the EG3.com DSP Knowledge Pack on group delay and the Fred Harris 600 tap example. Fair enough. But is that number simulated in double precision or measured after coefficient quantization to Q31 on a real Cortex M? The difference can be 6 dB in the stopband. Compared to what implementation? Datasheet numbers or bench data at 720 MHz on the TMS320C6416? Missing context changes the tap count you actually need.

Dave's Take

Dave's Take: The ARM CMSIS DSP speedup claims look good on the GitHub page. What is the actual cycle count when you also have to shuffle samples into the right buffers for Helium? 2 to 4 times sounds nice. Is that versus naive C or versus a hand tuned assembly version on the same chip? Source matters when your MCU budget is already tight.

Dave's Take

Dave's Take: Butterworth rolloff at 20 dB per decade per order is textbook. Yet FIR tap counts explode once transition bandwidth tightens. The article gives the math but skips how much RAM those 600 taps eat on a typical fixed point DSP. Is the rule of thumb still practical when your on chip memory is only 5 Mbit like the ADSP 21489? Context is everything.

FIR vs. IIR: Spec Comparison for Common Use Cases

A 4th order Butterworth IIR delivers roughly the same rolloff as a 40 tap FIR. That gap drives most hardware choices in embedded audio.

One look at the table below shows why the tradeoffs matter. FIR offers linear phase. IIR eats far fewer cycles.

According to DSP academic paths the field remains a specialization inside electrical engineering or computer engineering. Key courses cover exactly these tradeoffs. TI TMS320 overview notes that a DSP uses Harvard architecture with single cycle multiply accumulate hardware. This makes FIR feasible on dedicated silicon where a general CPU would choke.

Where FIR Wins: Audio, Communications, and Phase-Sensitive Paths

FIR shines when phase distortion destroys the signal. Audio crossovers need linear phase so drivers stay in time. Communications systems using QAM demodulation fall apart with group delay variation. Smart speakers like Amazon Echo use 7 microphone arrays for beamforming and those paths run adaptive FIR filters that update around 1000 times per second.

Telephone audio runs at 8000 Hz sampling and captures up to 4000 Hz voice bandwidth. It often uses IIR for anti aliasing. Audio CD uses 44100 Hz sampling and captures up to 22050 Hz. Those reconstruction filters are almost always FIR. The constant delay of FIR stays predictable. You can compensate for it.

EG3.com DSP Knowledge Pack data shows the pattern holds across professional products. I've torn apart enough boards to see the pattern. The chips that ship with linear phase filters rarely need post processing fixes. Worth knowing that once you need phase accuracy the FIR path stops feeling expensive. That's just how it shakes out.

Dave's Take:

Dave's Take: The table claims a 4th order Butterworth matches a 40 tap FIR. Compared to what stopband spec? Bench data on a real 44.1 kHz CD reconstruction chain or textbook math in double precision? Dave wonders if the smart speaker beamforming example uses floating point or fixed point. Those details shift the compute cost by 3x or more. Source on the 1000 updates per second would help.

Where IIR Wins: Low-Latency Control Loops and Tight Compute Budgets

IIR wins when latency budget sits under 3 ms or your MCU already runs hot. A few multiply accumulate operations beat hundreds of taps. Control loops tolerate the nonlinear phase. Sensor smoothing cares more about rolloff than perfect delay.

The thing is most battery powered gadgets live here. Wake word detection runs under 1 mW partly because the front end filter stays cheap. You accept some phase shift to stay under the power cap.

And yeah the design feels trickier. Quantization can push poles outside the unit circle. MIT OCW 6.341 still serves as the classic free course for learning those gotchas. I find it funny how many prototype filters look perfect until they hit the actual silicon.

Common Failure Modes in the Field

A prototype filter on a development board sounded clean until it shipped in volume. Then customers reported harmonic content that the simulation never showed. That's the catch with bench testing, it didn't expose the problem. The transition bandwidth proved too wide once real transducers entered the picture.

Dedicated silicon still earns its spot on certain jobs. It's fast. General purpose chips handle most workloads fine, but when you're pushing real time signal processing or sub-millisecond latency requirements, dedicated silicon doesn't flinch where a general purpose chip would start dropping the ball and forcing you into expensive software workarounds.

Dedicated DSP Silicon: When the TMS320 or SHARC Is the Right Call

TI lists the TMS320C6720 at 350 MHz clock with 2800 MIPS and 2100 MFLOPS while running 32 or 64 bit floating point. Analog Devices rates the ADSP-21489 at 450 MHz with 2700 MFLOPS, 5 Mbit on chip RAM and 32 bit or 40 bit floating point support. Both chips include hardware circular addressing. That turns FIR delay line management into zero overhead.

Typical DSP chip costs run from 5 to 50 dollars. That sits between microcontrollers and FPGAs. If you need deterministic latency and you run long filters these parts remove entire classes of bugs. The Harvard architecture keeps data and program buses separate so MAC operations stay single cycle.

EG3.com DSP Knowledge Pack notes that 44100 Hz was chosen because PAL video tape math produced exactly that rate. Richard G. Lyons received IEEE Signal Processing Society Educator of the Year 2012 and his book still sits on benches like mine. I have seen these DSPs handle 256 tap filters without breaking a sweat while the nearby MCU begged for mercy. For most audio filtering tasks under 128 taps a Cortex M4 with CMSIS DSP is all you need and it costs under 3 dollars.

Dave's Take:

Dave's Take: TMS320C6720 specs look strong on paper at 2100 MFLOPS. But is that sustained or peak with zero cache misses? The ADSP-21489 5 Mbit RAM figure sounds generous until you allocate buffers for multiple microphone arrays. Dave wants measured power at 720 MHz on the older TMS320C6416 for comparison. Datasheet optimism meets thermal reality in the field.

Cortex-M4/M7 With CMSIS-DSP: The $3 Option That Usually Works

Most jobs I see these days land on a Cortex M part. CMSIS DSP library handles the circular buffers internally. It's fast. A 512 point FFT finishes in roughly 120 microseconds on STM32F4, and that's a number that doesn't lie when you're budgeting cycles for a real project. Scale that to a 64 tap FIR at 48 kHz and the cycles disappear.

You pay three dollars instead of thirty. The vector extensions on M7 or the ESP32 S3 vector unit drop that further. For anything under 128 taps the performance lands well inside budget. Over that mark you start watching your MIPS disappear fast.

The 44100 Hz sample rate example still governs most audio work. Simulations in MATLAB that costs around 2000 dollars plus toolboxes can hide quantization effects. I learned that lesson the hard way once. Verify on the actual target silicon before you commit the firmware.

Common Failure Modes in the Field

If your fixed point coefficients sum above 1.0 the accumulator saturates. The output clips and you chase a bug that looks like distortion but lives in the math.

Coefficient Overflow and Fixed-Point Saturation

Q15 coefficients look innocent until you add them all up. Scale the entire set by 0.8 or so then add a compensating gain stage after the filter. Skip that step and every loud passage clips. The DSP academic paths material makes this clear in the fixed point labs.

According to Goodreads Discrete Time Signal Processing by Oppenheim and Schafer holds a 4.06 out of 5 rating with the third edition running 1144 pages. Goodreads gives DSP Principles Algorithms and Applications by Proakis and Manolakis 3.93 out of 5 and calls it the most shelved DSP book. Those texts walk through the scaling math.

A bare metal implementation without hardware circular addressing compounds the problem. Pointer mismanagement turns the delay line into garbage. CMSIS DSP removes that headache on Cortex parts, and you don't have to babysit pointer arithmetic to get there. Still test the edge cases or you'll ship noise.

Insufficient Tap Count: When the Stopband Leaks

For 60 dB stopband attenuation with a transition band of Fs over 100 you need approximately 600 FIR taps. Drop below that and energy leaks through. It folds back as aliasing or raised noise floor. Audio starts to sound gritty in ways customers notice immediately.

The TI TMS320 overview highlights how circular addressing and deterministic latency matter when you chase those taps. Without them the filter cannot keep up. Simulation in double precision looks fine. Quantized to Q31 on the real chip the stopband jumps 6 dB worse.

Verify your frequency response in simulation before you burn the firmware. That single check prevents most field returns. 600 taps sounds like a lot until you hear what 200 delivers in a real product.

Dave's Take:

Dave's Take: The 600 tap number for 60 dB at Fs/100 comes from theory. What's the measured stopband on a 44.1 kHz system after quantization and with actual transducer response? Oppenheim's 1144 page book probably covers it but Dave questions whether most teams simulate the full signal chain including the DAC. Theory meets silicon and the difference often exceeds 10 dB. Source the exact simulation conditions next time.

Frequently Asked Questions

What happens when the numbers in your filter design refuse to match the datasheet promises?

How many taps does a FIR filter need for audio applications?

Depends on transition bandwidth and required stopband attenuation. A 60 dB stopband with a transition band of Fs over 100 needs roughly 600 taps. Most audio crossover filters get by with 64 to 256 taps. Use the Fred Harris rule of thumb to estimate before you start coding. The Scientist and Engineer's Guide to DSP by Steven W. Smith rates 4.57 out of 5 on Goodreads. That book walks through the practical math.

What is the group delay of a FIR filter and does it matter?

Group delay equals N minus 1 divided by 2 samples where N is the tap count. A 101 tap FIR at 48 kHz adds exactly 1.04 ms of latency. It matters in real time audio monitoring and acoustic echo cancellation systems where latency budget is tight. The delay stays constant across all frequencies. That consistency is the reason many engineers accept the compute cost.

Understanding DSP by Richard G. Lyons rates 4.47 out of 5 on Goodreads. I keep a dog eared copy on the bench. The graphs make the latency tradeoffs obvious in about five minutes.

Can a FIR filter run on an ESP32 or similar microcontroller?

Yes. The ESP32 S3 handles a 512 point FFT in about 50 microseconds using its vector unit. A 64 tap FIR at 48 kHz sampling is well within budget. For anything over 256 taps at high sample rates move to a Cortex M7 or dedicated DSP chip. Power and RAM become the limiting factors faster than you expect.

When should I use IIR instead of a FIR filter?

Use IIR when compute budget is tight and phase linearity is not a requirement. A 4th order IIR Butterworth gives roughly the same rolloff as a 40 tap FIR at a fraction of the multiply accumulate cost. Control loops, anti aliasing, and sensor smoothing are natural IIR territory. The design requires more attention to stability but the cycle savings justify it on tight platforms.

Does Parks-McClellan always produce a better FIR filter than the window method?

For a given tap count yes. Parks McClellan minimizes the maximum error across both passband and stopband so you get sharper rolloff with fewer taps than any window based design. The window method is faster to implement and fine for non critical applications where a few extra taps are not a problem. MATLAB licenses run around 2000 dollars plus 1000 per toolbox for commercial work. That cost pushes teams toward the quicker path until specifications tighten.

Range resolution equals c divided by 2 times bandwidth. A 77 GHz automotive radar with 150 MHz bandwidth delivers 1 meter resolution while 4 GHz bandwidth improves it to 3.75 cm. The same math governs how sharply your filter can separate frequencies. Choose tap count accordingly or accept the leakage.

The numbers only tell part of the story. Grab the actual silicon run the filter and watch the spectrum analyzer. That bench truth beats every textbook rating.