One of the facts which I have blogged about before, was that an important type of filter, which was essentially digital, except for its first implementations, was called a ‘Sinc Filter‘. This filter was once presented as an ideal low-pass filter, that was also a brick-wall filter, meaning, that as the series was made longer, near-perfect cutoff was achieved.

Well, while the use of this filter in its original form has largely been deprecated, there is a modern version of it that has captured some popularity. The Sinc Filter is nowadays often combined with a ‘Kaiser Window‘, and doing so accomplishes two goals:

- The Kaiser Window puts an end to the series being an infinite series, which many coders had issues with,
- It also makes possible Sinc Filters with cutoff-frequencies, that are not negative powers of two, times the Nyquist Frequency.

It has always been possible to design a Sinc Filter with 2x or 4x over-sampling, and in some frivolous examples, with 8x over-sampling. But if a Circuit Designer ever tried to design one, that has 4.3 over-sampling, for example, thereby resulting in a cutoff-frequency which is just lower than 1/4 the Nyquist Frequency, the sticky issue would always remain, as to what would take place with the last zero-crossing of the Sinc Function, furthest from the origin. It could create a mess in the resulting signal as well.

Because the Kaiser Windowing Function actually goes to zero gradually, it suppresses the farthest zero-crossings of the Sinc Function from the origin, without impeding that the filter still works essentially, as the Math of the Sinc Function would suggest.

Further, even Linux utilities such as ‘ffmpeg’, employ a Sinc Filter by default when resampling an audio stream, but with a Kaiser Window.

(Updated 8/06/2019, 15h35 … )

(Update 8/05/2019, 22h00 : )

I suppose that a kind of question which could be asked would be, of whether the mere application of the Kaiser Window truly brings the value of the outermost weights of the Sinc Function to zero. The Kaiser Window first computes a familiar function of the sample-position within the window, then multiplies that by the term (πα), then computes the Zero-Order Modified Bessel Function of the result, and then *divides the result of that by the Modified Bessel Function of (πα)*. Because many programmers don’t like to work with constants such as (π) repeatedly, they often replace the term (πα) with (β). And so the maximum degree by which the Kaiser Window will attenuate its outermost regions, depends on the behaviour of the Modified Bessel Function, which is, to start at (1.0) when the parameter is zero, and to become larger with increasing parameter-values, in a way that accelerates.

‘ffmpeg’ will use a default value for (β) of *(9.0)*, but will not permit the user to set this value lower than (2.0), essentially, to prevent the user from shooting himself in the foot. The only real situation in which the user should change this value of (β), is if he’s sure that he has computed the cutoff frequency such, that the outermost zero-crossings of the Sinc Function correspond closely enough to an integer sample-position, at both edges of the sampling window. But even then, setting (β) to (2.0) will mean, that an attenuation of approximately (2.28) will still take place. The corresponding Bessel Function of (9.0) is (1093.6) .

The reason for which the Kaiser Window is relatively expensive to compute, is the fact that the correct version of the Bessel Function needs to be computed *(L/2 times)*, in order to compute a Kaiser Window. Even though Algebra can be used to state the second-order differential equation, which the Bessel Function is the solution to, there is no closed-form, ordinary Algebraic solution to the Bessel Function. It can be named. But then, if a numerical approximation is desired, an infinite series has been defined which converges, so that a finite number of elements of that series can be computed, to whatever level of accuracy is required of the numerical approximation.

This situation is similar to how it is with basic trig functions, such as the Sine Function. It can be written, but then, to compute a numerical value for it, requires that a specialized computation be performed. There is no regular (exact) Algebraic solution, to what the Sine of an arbitrary parameter is, *most of the time*.

The important difference when trying to assess how computationally expensive the Bessel Function is on personal computers and appliances however, lies in the fact that the Floating-Point Unit of a typical CPU will have specialized hardware, that computes the standard trig functions, but no specialized hardware to compute the Bessel Function.

What this means is that precalculated Kaiser Windows could be embedded, but applications are not usually embedded, which need to recompute the Kaiser Window with different values for (β).

(Update 8/06/2019, 15h35 : )

```
This is Yacas version '1.3.6'.
Yacas is Free Software--Free as in Freedom--so you can redistribute Yacas or
modify it under certain conditions. Yacas comes with ABSOLUTELY NO WARRANTY.
See the GNU General Public License (GPL) for the full conditions.
Type ?license or ?licence to see the GPL; type ?warranty for warranty info.
See http://yacas.sf.net for more information and documentation on Yacas.
Type ?? for help. Or type ?function for help on a function.
To exit Yacas, enter Exit(); or quit or Ctrl-c.
Type 'restart' to restart Yacas.
To see example commands, keep typing Example();
In> N(BesselI(0, 2.0), 50);
Out> 2.279585302336067267437204440811533353285841102785459
In> N(BesselI(0, 9.0), 50);
Out> 1093.5883545113746958458242514254708426094639321617357151
In> Exit();
Out> True
Quitting...
```

One of the behaviours of the Numerical Toolbox ‘Yacas’ is, if told to print a numerical result to 50 decimal places, actually to print more than 50 decimal places, out of which *only the first 50 will be accurate*. And, the digits *before* the decimal point supposedly *belong to* the 50 accurate digits.

Dirk