A lot is made of the differences between IIR and FIR filters for high-end audio applications. FIR stands for Finite Impulse Response, and IIR stands for Infinite Impulse Response. It is perhaps not surprising, therefore, that in discussing the characteristics of various filters, the the one thing you tend to read more often than any other is that IIR filters have this or that type of impulse response, whereas FIR filters have such and such an impulse response, as though the impulse response itself were the purpose of the filter. Nothing could be further from the truth.
Although an impulse response has a waveform-like aspect, and is derived directly from the frequency and phase responses of the filter, there is an unfortunate affectation which is common in the world of high-end audio to characterize the audible characteristics of a filter in terms of the features of its impulse response. It is a bit like saying, with the smug certainty of one stating the self-evidently obvious, that the number of a bus tells you where the bus is going. Where I live, there is a bus route that goes to the airport, which has the (to me, at any rate) faintly amusing route number of ‘747’ (the famous Boeing 747 is the eponymous Jumbo Jet). When I see the 747 bus I know it is going to the airport, but it would be wrong to deduce that the bus has an upper deck (which it doesn’t, as it happens), or that it holds more passengers than the average bus (which it also doesn’t). Neither would it be wise to assume in other cities around the world, that the way to get to the airport is to take the 747 bus.
All digital filters, whether IIR or FIR, work by manipulating the available data. Broadly speaking, the available data comprises two sets of numbers. One set is the actual music data that gets fed into the filter. The other is the set of numbers comprising the previous outputs of the filter. In practical terms, the primary distinction between FIR and IIR filters is that FIR filters are confined to using only the actual music data as its inputs, whereas the IIR filter can use both.
The impulse response of an FIR filter is nothing more than a graphical representation of the so-called ‘taps’ of the filter. Each ‘tap’ represents one of the actual input music data values, so the more ‘taps’ the filter has, the more of the input music data goes into the calculation of each output value. The more complex the performance requirements of an FIR filter, the more ‘taps’ are needed to define it, and the more detail will be found in its impulse response. With an IIR filter, however, its calculation uses previous output values as well as previous input values, and of course each previous output value will have been calculated from the input and output values before that. As a result, if you were to go through all the math, you would find that an IIR filter can be re-written in a form that uses ALL of the actual music input values, and NONE of the previous output values to calculate each new output value. For this reason, it is mathematically identical to an FIR filter with an infinite number of taps. Hence the term “Infinite” Impulse Response. But the IIR filter can achieve this with a surprisingly compact filter structure, one that uses relatively few of the previous input and output values, and obviously requires very many fewer calculations in order to arrive at the exact same result.
The biggest practical and worthwhile difference between FIR and IIR filters actually lies in the tools that are used to design them. To learn more you need to read my previous posts on “Pole Dancing” where I discuss the basics of filter design. This involves nothing more than placing a bunch of “Poles” and “Zeros” on a graph called a Z-space. Once you have the poles and the zeros positioned, the digital filter itself is pretty much defined. The problem is that the relationship between the performance of the filter and the location and number of poles and zeros is not a two-way street. If I have my poles and zeros, I can easily calculate the frequency, phase, and impulse responses of my filter. But if I start by defining the responses that I want from my filter, it is not possible to make the opposite calculation, and derive the requisite poles and zeros. In other words, when it comes to digital filter design, the operative phrase is usually “you can’t get there from here”.
The way we get around this bottleneck is the same way we get around every other tricky mathematical problem. We reduce the complexity of the problem by simplifying it, and only considering a strict subset of the total spectrum of possibilities. I’m not going to get into the technical details, but the outcome of that approach is that we end up with certain design methods that can be used to design certain classes of filters. In other words, design tool for FIR filters produce slightly different results than design tools for IIR filters. The extent to which FIR and IIR filters differ in any audible sense is more down to whether design tools available in IIR or FIR space do a better job of realizing the desired output response.
Aside from the challenges faced in designing the filter, there are significant distinctions between IIR and FIR filters when it comes to actually implementing the filter. In general IIR filters are very efficient. Rarely do they have more than 10-20 ‘taps’ (a term not actually used when referring to IIR filters). Therefore they tend to be inherently more efficient when run on computer architectures. IIR filters can be very compact, and are usually designed to run in sequential blocks, with the output of one block forming the input to the next. On the other hand, FIR filters lend themselves really well to being realized in massively parallel architectures. For each FIR filter tap we need to multiply two numbers together, and when that’s done add all the answers together. None of these multiplications rely on the outcomes of any of the other multiplications, so they can all be done in parallel.
In a computer you usually don’t have many parallel processing paths available, but an FPGA can be easily programmed to do hundreds of operations in parallel. An FIR filter with hundreds upon hundreds of taps can therefore be realized very efficiently indeed in an FPGA. Additionally, FIR filters are stable when implemented using Integer arithmetic, something that will rapidly trip up an IIR filter. The ability to use integer arithmetic is something else that can be quite significant in an FPGA and less so in a computer. ‘Efficiency’ is critically important in the majority of audio applications which have to operate in ‘real time’, and will fail if they run more slowly than the music which they are processing!
For all of those reasons, and also because the design tools available for IIR filters are generally a better match to the performance characteristics we are usually looking for, here at BitPerfect our preference is inevitably for an IIR filter. And the filter we choose is one whose performance characteristics are the closest to what we need, regardless of what the impulse response might look like. The filter we will offer is always the one which sounds best to us, rather than the one whose impulse response meets some perceived aesthetic ideal.
