Without the possibility to adjust the volume of individual frequency bands within an audio signal, modern audio would not sound the same. Today I’d like to show how I’ve implemented a EQ within my FPGA audio-mixer.
In this blog-post I won’t describe the general idea of an EQ, because there are more capable persons available doing this, like Vesa Välimäki and Joshua Reiss with their All About Audio Equalization: Solutions and Frontiers. But I want to share with you, how I implemented an audio-filter within my Cyclone 10LP to create an EQ and crossovers.
Selecting the right filter-type
As the Cyclone 10LP of the Arduino MKR Vidor4000 is quite limited in its available logic-elements and multiplication-blocks, I searched for a solution to implement an equalizer with a low logic-demand and ressource-footprint. For audio-applications two filter-types come into question: besides the FIR-filters, infinite impulse response-filters (IIR) are using only a limited number of samples from the past, to calculate the desired result: three values for each, input and output. IIR-filters have a low latency and low calculation-demand, while FIR-filters are more stable and linear. As the reducation of ressource-demand and latency were my primary goals, I had a deeper look at the IIR-filters. To calculate this Biquad-IIR-filter (because it has two poles and two zeros), I had to create a storage for two samples of the past for each input and output. These values are then multiplied with a specific coefficient, that defines what type of filter we are creating:
The resulting difference equation that defines how the output signal is related to the input signal for a simple equalizer follows the following equation:
With these six coefficients a0…a2 and b0…b2 we can control the general behavior of the filter. The online-tool Biquad calculator v3 next to the Audio-EQ-Cookbook can be used to calculate all coefficients to form a low-pass, high-pass, peak or shelf-filter using the previous equation. To get rid of the division, the coefficients a0…a2 and b1…b2 can be divided by b0, before sending them to the FPGA.
VHDL-implementation
Now that I had chosen a fitting algorithm I had to implement these filters in VHDL. First I had to define the inputs and outputs for this EQ:
port (
clk : in std_logic := '0';
sample_in : in signed (23 downto 0) := (others=>'0'); -- audio-sample
sync_in : in std_logic := '0';
sample_out : out signed(23 downto 0) := (others=>'0'); -- audio-sample
sync_out : out std_logic := '0';
-- 32-bit filter-coefficients set by microcontroller
a0 : in signed(31 downto 0);
a1 : in signed(31 downto 0);
a2 : in signed(31 downto 0);
b1 : in signed(31 downto 0);
b2 : in signed(31 downto 0)
);As we need five multiplications of a 24-bit-sample with a coefficient with at least 32-bit for each path, we end up using already 18% of our 112 DSP-multiplicator-sections (DSP-slices) for one single EQ. To mitigate this bottleneck, the first thing was implementing a reusable multiplication-process within the FPGA:
architecture Behavioral of filter_iir is
--signals for multiplier
signal mult_in_a : signed(bit_width - 1 downto 0) := (others=>'0'); -- input signal
signal mult_in_b : signed(31 downto 0) := (others=>'0'); -- coefficient
signal mult_out : signed(bit_width + 32 - 1 downto 0):= (others=>'0');
-- [...]
begin
-- multiplier
process(mult_in_a, mult_in_b)
begin
mult_out <= mult_in_a * mult_in_b;
end process;
-- [...]Now that we have a single multiplication-process, that can be called several times, we reduced our demand of DSP-slices from 17% to below 4% – but at the expense of pure logic-elements. OK, now that I was able to calculate the nescessary multiplications with a reasonable effort, I had to think about the specific resolution of the multiplication. Simply multiplying the coefficients with the audio-samples was not enough: calculating the coefficients for a standard peak-filter at 48kHz samplerate, a center-frequency of 4400 Hz and some common values for gain and Q we end up with the following coefficients:
| # | a | b |
|---|---|---|
| 0 | 1.1754725057104447 | 1.0 |
| 1 | -1.178299973845067 | -1.178299973845067 |
| 2 | 0.22451194282761486 | 0.39998444853805976 |
So multiplying any audio-sample with a2 or b2 would result in 0 if we are using integer-multiplication. As the FPGA has no floating-point-unit, all multiplications are integer-multiplications. But we can introduce fixed-point-numbers simply by bit-shifting individual signals. So I shifted the coefficients 30 bits to the left to get a signed Q1.30 number. The same I did for the audio-samples, but only with 8-bits, to get a signed Q23.8 number to have a 32-bit number on both sides of the multiplication. The first step of the state-machine looks like this:
if (rising_edge(clk)) then
-- start process when valid sample arrived
if (sync_in = '1' and state = 0) then
mult_in_a <= shift_left(sample_in, 8); -- convert to Qx.8 and load sample into multiplication-process
temp_in <= shift_left(sample_in, 8); -- convert to Qx.8 and store sample for later
mult_in_b <= a0; -- load coefficient to multiplication-process
state <= 1; -- go to the next state
-- [...]As the multiplication is using special DSP-slices of the FPGA, the multiplication is done within one clock-cycle. The only thing I had to consider is the fact, that multiplying a signed Q1.30 number with a signed Q24.8 number will result in a signed Q25.38 number – a 64 bit value. So I had to reshift the resulting audio-sample 30 bits back to the right and resize it to a 32-bit value, to get a signed Q23.8 value again. The following code-snippet shows the remaining states 1 to 7 of the state-machine:
elsif (state = 1) then
-- save result of (sample_in*a0) to temp and apply right-shift of 30
-- and load multiplier with in_z1 and a1
temp <= resize(shift_right(mult_out, 30), 24 + 8);
mult_in_a <= in_z1;
mult_in_b <= a1;
state <= 2;
elsif (state = 2) then
-- save and sum up result of (in_z1*a1) to temp and apply right-shift of 30
-- and load multiplier with in_z2 and a2
temp <= temp + resize(shift_right(mult_out, 30), 24 + 8);
mult_in_a <= in_z2;
mult_in_b <= a2;
state <= 3;
elsif (state = 3) then
-- save and sum up result of (in_z2*a2) to temp and apply right-shift of 30
-- and load multiplier with out_z1 and b1
temp <= temp + resize(shift_right(mult_out, 30), 24 + 8);
mult_in_a <= out_z1;
mult_in_b <= b1;
state <= 4;
elsif (state = 4) then
-- save and sum up (negative) result of (out_z1*b1) and apply right-shift of 30
-- and load multiplier with out_z2 and b2
temp <= temp - resize(shift_right(mult_out, 30), 24 + 8);
mult_in_a <= out_z2;
mult_in_b <= b2;
state <= 5;
elsif (state = 5) then
-- save and sum up (negative) result of (out_z2*b2) and apply right-shift of 30
temp <= temp - resize(shift_right(mult_out, 30), 24 + 8);
state <= 6;
elsif (state = 6) then
-- save result to output, save all delay registers, apply ouput-valid signal
sample_out <= resize(shift_right(temp, 8), 24);
out_z1 <= resize(temp, 24);
out_z2 <= out_z1;
in_z2 <= in_z1;
in_z1 <= temp_in;
sync_out <= '1';
state <= 7;
elsif (state = 7) then
sync_out <= '0';
state <= 0;
end if; That’s it. After 7 clocks, we are back in the idle-state and ready to receive the next audio-sample. With an FPGA-clock of 100MHz this means only 70ns for the calculation of this IIR-filter. While having the total available logic in mind, we can concatenate individual IIR-filters to build up a whole parametric equalizer with 5 or more individual setpoints. With the six individual coefficients we are then able to create several different audio-filters:
| Common | Special |
|---|---|
| Peak | Notch |
| High-/Low-Shelf | Bandpass |
| High-/Low-Pass | Allpass |
Crossover with steeper slope
Using these six coefficients results in the already mentioned Biquad-IIR-filter, which are filters of second-order with 12dB/octave. This is fine for general equalizing, but if you want to separate the lows for a subwoofer from the highs for the tweeters, this will produce a +3dB gain at the transfer-point if both filters are set to the same frequency. So, Siegfried Linkwitz and Russ Riley developed a new type of filter as an improved Biquad-filter: the Linkwitz-Riley-Filter. Fourth-order Linkwitz–Riley crossovers (LR4) are probably today’s most commonly used type of audio crossover. They are constructed by cascading two 2nd-order filters. Both filters can be combined in one single VHDL-block while increasing the number of coefficients:
port (
clk : in std_logic := '0';
sample_in : in signed(23 downto 0) := (others=>'0');
sync_in : in std_logic := '0';
rst : in std_logic := '0';
-- coefficients have to be multiplied with 2^fract_bits before
a0 : in signed(coeff_bits - 1 downto 0);
a1 : in signed(coeff_bits - 1 downto 0);
a2 : in signed(coeff_bits - 1 downto 0);
a3 : in signed(coeff_bits - 1 downto 0);
a4 : in signed(coeff_bits - 1 downto 0);
-- coefficients have to be multiplied with 2^fract_bits before
b1 : in signed(coeff_bits - 1 downto 0);
b2 : in signed(coeff_bits - 1 downto 0);
b3 : in signed(coeff_bits - 1 downto 0);
b4 : in signed(coeff_bits - 1 downto 0);
sample_out : out signed(23 downto 0) := (others=>'0');
sync_out : out std_logic := '0'
);Not only the number of coefficients has now increased, but the nescessary resolution for the multiplication, too. Using a resolution of at least 40-bit is suggested. The resultion equation is an enhanced version of the previous equation:
The additional multiplications will increase the overall calculation-time: instead of 70ns at 100MHz, the fourth-order Linkwitz-Riley-filter will now take 11 states, so 110ns in total for a mono-channel. Two or three channels can be calculated at the same time, which gives us a good compromise between logic-demand and usage of DSP-slices. If you like, you can have a deeper look at the full-featured crossover-filter at my Audioplayer-project at GitHub: filter_lr24_crossover.vhd
Calculation of the coefficients
If you do not like to use the online-Biquad-Calculator each time you want to adjust your EQ, there is a better way. I implemented the calculation of the individual coefficients in the ESP32 of the Vidor 4000. The only parameters I have to select are:
- Type of EQ
- Frequency
- Gain
- Q-Factor
For a simple peak-filter the general calculation looks like this:
void recalcFilterCoefficients_PeakFilter(struct sPEQ *peq) {
double V = pow(10.0, fabs(peq->gain)/20.0);
double K = tan(PI * peq->fc / audiomixer.sampleRate);
double norm;
double coeff_a[3];
double coeff_b[3];
// check if we are attenuating or boosting this frequency
if (peq->gain >= 0) {
norm = 1.0 / (1.0 + 1.0/peq->Q * K + K * K);
coeff_a[0] = (1.0 + V/peq->Q * K + K * K) * norm;
coeff_a[1] = 2.0 * (K * K - 1.0) * norm;
coeff_a[2] = (1.0 - V/peq->Q * K + K * K) * norm;
coeff_b[1] = coeff_a[1];
coeff_b[2] = (1.0 - 1.0/peq->Q * K + K * K) * norm;
}else{
norm = 1.0 / (1.0 + V/peq->Q * K + K * K);
coeff_a[0] = (1.0 + 1.0/peq->Q * K + K * K) * norm;
coeff_a[1] = 2.0 * (K * K - 1.0) * norm;
coeff_a[2] = (1.0 - 1.0/peq->Q * K + K * K) * norm;
coeff_b[1] = coeff_a[1];
coeff_b[2] = (1.0 - V/peq->Q * K + K * K) * norm;
}
// convert to Q30-format
for (int i=0; i<3; i++) {
peq->a[i].s32 = coeff_a[i] * 1073741824; // convert to Q30
peq->b[i].s32 = coeff_b[i] * 1073741824; // convert to Q30
}
}The calculation of the other types of filters are slightly different. The full source-code is available in the Audioplayer-Repository at GitHub. In the file Mixerengine.ino you will find the function “recalcFilterCoefficients_PEQ(…)” where all different types of Biquad-Filters are calculated. Furthermore, you will find the calculation of a 2nd-order Linkwitz-Riley-Filter in the function “recalcFilterCoefficients_LR12(…)” and the 4th-order LR24 in the function “recalcFilterCoefficients_LR24(…)”
Tests
At the university I have access to several high-level-devices. For my first tests, I used an Omicron Bode 100 Analyzer connected to both the input and output of the Cyclone 10 LP and measured the frequency-response (see the featured picture of this blog-post). As this device costs around 5000,-€ there is a better and free solution if you do not own such a device: download and install the Room EQ Wizard (REW) Software. This software is intended to analyze and measure the frequency-response of a whole room using a reference-measurement-microphone. But nobody stops you from not putting a mic in the audio-path, but only an audio-device directly. So the REW-software will not measure the frequency-response of the room, but only of our device-under-test. Here you can see two different overlayed frequency-responses using a test-signal without an EQ (blue) and with an EQ (yellow):
You can find more files in my GitHub-repositories, especially the Audioplayer with EQ, or the Elektor article about the FPGA-based Audioplayer with Equalizer