Sound filtering tool for creating loudspeaker crossovers.
FIR - finite impulse response.
A list of numbers obtained by recording the response of a system after being hit by an impulse.
In physical audio terms this is the sound that an object will produce when hit by a small hammer.
It completely describes a vibrating system. The hit is an 'impulse' and the afterwards ringing is
the response. Because theoretically this response can be infinite, thus this clarification - Finite.
Sometimes called 'convolution kernel' or just 'the filter'. Can be synthetically generated by a lot
of online tools.
Convolution
Is a simple mathematical operation.
It is used in Image processing to do Blur, Sharpen, Edge-Detection and other filters.
In Audio it is used for the same thing but with different names.
Blur becomes 'low-pass filter', Sharpen becomes 'high-pass filter' ...
It can be N-dimentional but in audio we care for the 1-dimentional variant only.
Formula:
output[n] = input[n]*filter[n] + input[n-1]*filter[n+1] + ... + output[n-flen]*filter[n+flen]
where filter is a sequence of numbers just like input and output, and flen is its length.
FIR filtering
When a signal is convolved with a recorded or generated FIR, the output will be as if the signal
was input to that system. In physical audio terms - if we record the echo after a clap in an empty room,
and use that wave as convolution kernel to convolve an audio track, then the output will be as if the
audio track was played in that empty room.
SIMD - single instruction multiple data
It turns that this simple convolution algorithm is very computation expensive and
almost no practical results can be achieved without some kind of hardware acceleration.
By hardware acceleration i mean - a way to multiply more than 2 numbers in a single cpu clock cycle.
Happyly such an acceleration is available in most cpus. Intel/AMD has AVX and ARM has Neon.
Both of them can do roughly around 10 multiplications per cycle.
Multi-threading
Convolution is 100% parallelizable. Meaning that the speed is directly proportional to
the number of cores the cpu has. Doubling the cores/threads will double the speed.
Clock Correction
Also called 'clock drift syncronization' or 'stream syncronization'.
When the two clock speeds are not only different but also vary in time then this causes 'jitter'.
In simple words it is about reversing the effect of buffer overflows or buffer underflows
caused by the two slightly different speeds at wich a buffer is simultaneously writen and read.
In audio terms - if we have an audio device giving us 44100 samples per second, and then another
audio device taking from us 44101 samples per second then the buffer of this stream will be
completely empty after several minutes. If we swap the devices then the buffer will grow forever,
causing the playback to drift into the past. Thus sometimes when we watch a movie we notice that
the audio is coming after the picture, and the effect grows as the movie rolls.
My solution is to replay or skip a sample or two per second. It is completely unaudiable.
Currently RTFIR runs only on Windows with Intel or AMD cpus, and makes use of the AVX instruction set.
The AVX implementation of the convolution is happyly stolen from Henry Gomersall without his permision.
It is written with porting in mind but no real job had been done in that direction.
The two main difficulties about porting would be the UI and the ARM Neon implementaion of convolution.
For the UI i chose to use NAppGui - simple UI and OS abstraction that compiles everywhere.
After linking with NAppGui it should compile on linux/mac/raspberry but not accelerated.
Because RTFIR cannot create system-wide audio devices, you should either use a virtual audio cable,
or the build-in loopback devices to filter the sound from browser/youtube.
I use VB-CABLE.
RTFIR comes with several pre-made filters so you can test directly, but it cannot create filters.
You should use other software for generating them - like REW or some online tools.
I use REPHASE.
Downloads in the Release section.
