I've had an STM32F4 discovery for years. I've experimented with the I2S and audio but not with DSP so your videos have been great. I've done DSP before using MAX/MSP. You inspire me to work on audio DSP using my Disco board. I also got hold of an STM3220G EVAL board recently,,LOADS of peripherals. :)
Hi, Thanks for your video, really helpful so start audio on STM32. For me there are a few mistakes in your video : - The "Ratio" parameter is not the gain reduction (in dB), but the factor by which the level over the threshold is multiplied (in dB). For example, a ratio of 6:1 doesn't mean that you have to reduce the signal by 6dB (/2) when you go over the threshold (what you did). It means that if you have a signal 6dB over the threshold, then you have to reduce it to 1dB over the threshold (5dB reduction). A signal of 12dB over the threshold have to be reduced to 2dB over the threshold (10dB reduction). And with an infinite ratio, a signal x dB above the threshold will have to be sent back to threshold, so reduced by x dB : It is a limiter. - The state machine is also not good to me. For example, if you are in "Gain Reduction Hold" state and the signal goes up again, you have to go back to attack again to reduce a bit more, before the hold timeout is over. My algorithm would be, at each sample : - Calculate the level of the signal : It can be a peak level as you did, but can also be RMS value on a few samples - Calculate the "expected gain reduction" (timing not used here) depending on the input level (peak or RMS) and the threshold. If the input level is below threshold, the expected gain reduction is 0dB. If the input level is over threshold, then the expected output level over threshold is (input_level - threshold) / ratio, so the gain reduction is ( (input_level - threshold) - (input_level - threshold) / ratio ). In this way, with a ratio of 1, there is no reduction, and with an infinite ratio, there is a reduction of (input_level - threshold) which means everything above the threshold is send back to the threshold so the compressor act as a limiter - Finally, there is all the timing stuff to do and state machine. The final goal is to calculate the "actual gain reduction" depending on the "expected gain reduction" from this sample, the "previous expected gain reduction", attack, hold and release, and previous sample values. --- If the "expected gain reduction" is higher than the "previous sample expected gain reduction", it increase the limitation, the "actual gain reduction" = "previous sample actual gain reduction" + ("expected gain reduction" - "actual gain reduction from previous sample") / (FS * attack) => In that way, at each new sample, it goes a bit more close to the expected gain reduction, in an 1/exponential way. Also restart the Hold timer here. --- If the "expected gain reduction" is lower or equal than "previous expected gain reduction", it reduces the limitation. If hold timer is not over, don't change "actual gain reduction". If hold timer is over, reduce the "actual gain reduction" as done in "attack" part, but using release time - Multiply each sample with "actual gain reduction" (need to calculate from dB to linear) I might have done some mistakes in the algorithm, but I am sure about the definition of the ratio
Hey ! Today I looked over your excellent tutorial again. Some remarks from an audio engineers perspective: in the original code your attack/release timing looks odd..30mS for attack is long, 20 +10 for release is really short. In your real world example you did change the release timing by quite a bit, because it 'sounded horrible'..good! Now for the fun bit: There is actually 2 mistakes in the tx-rx complete callback routine as provide by CubeMX: 1. you have to repair the code to make the complete callback fire 2. the call back fires for both send and recieve DMA's so in fact you are running your interrupt code at twice the sampling speed If you look close at your Audacity recording you can see for example, that your attack timing is half of the expected 30ms (which works out to a 'ok sounding' 15mS) Anyway, keep up your good work!
Hi, thanks for your hints. That with the complete-callback I already figured out and fixed this in the HAL libraries during my first video on IIR filters. To be honest - that the callback is firing twice I was not aware. I checked that one time with the scope by toggling an IO with every callback and it was reasonable to me. However - thanks I'll check it once again.
Hi, yet another great tutorial. But I am having severe issues with audio to video synchronization here. Wondering why I am apparently the only one experiencing this issue?
Good work! I suppose that with LL drivers we can run this program on mini-board with stm32f103c8t6.It`s only needs a good 16bit ADC for stm32f103c8t6 .
adding attack allows you to shape the envelope of your signal such as allowing the initial tranient of a drum hit for "punch" and compressing the tail of the sound, which is shaped by the decay.
The audio and video sync is severely off (on the order of 1 minute or so). Any chance you could fix this and re-upload? Otherwise, this tutorial is great!
Hi, thanks for your video. I am working on a university project using the stm32f407vet6 board and an inmp441 microphone (www.aliexpress.com/i/32962426410.html), the configuration I have for i2s seems not to be right, and I am confused. Set my plli2s to 96Mhz and in i2s set the frequency to 96khz, Data and frame format: 24 bits on 32 bits, the communication standard as MSB First (according to datasheet). but the dms uses a uint16 structure, so I assume that the 32bits is divided into 2 and I try to reconstruct the data but I can't do it, is it possible to help me understand it? For now I need to read the data from MEMs i2s and remove it by microcontroller DAC whether to apply dsp treatment. If you have an example I will appreciate it.
![[#5] IIR Filters - Audio DSP On STM32 with I2S (24 Bit / 96 kHz)](http://i.ytimg.com/vi/lNBrGOk0XzE/mqdefault.jpg)
![[#5] IIR Filters - Audio DSP On STM32 with I2S (24 Bit / 96 kHz)](/img/tr.png)
![[#16] Guitar Distortion Effect - Audio DSP On STM32 (24 Bit / 48 kHz)](http://i.ytimg.com/vi/azLQf4aLv9w/mqdefault.jpg)
Enjoying these videos and learning a lot. I'm just getting started with I2S, been using ESP32 and SAMD51 but I'll try tthe STM32 again now.
I've had an STM32F4 discovery for years. I've experimented with the I2S and audio but not with DSP so your videos have been great. I've done DSP before using MAX/MSP. You inspire me to work on audio DSP using my Disco board. I also got hold of an STM3220G EVAL board recently,,LOADS of peripherals. :)
Hi,
Thanks for your video, really helpful so start audio on STM32.
For me there are a few mistakes in your video :
- The "Ratio" parameter is not the gain reduction (in dB), but the factor by which the level over the threshold is multiplied (in dB). For example, a ratio of 6:1 doesn't mean that you have to reduce the signal by 6dB (/2) when you go over the threshold (what you did). It means that if you have a signal 6dB over the threshold, then you have to reduce it to 1dB over the threshold (5dB reduction). A signal of 12dB over the threshold have to be reduced to 2dB over the threshold (10dB reduction). And with an infinite ratio, a signal x dB above the threshold will have to be sent back to threshold, so reduced by x dB : It is a limiter.
- The state machine is also not good to me. For example, if you are in "Gain Reduction Hold" state and the signal goes up again, you have to go back to attack again to reduce a bit more, before the hold timeout is over.
My algorithm would be, at each sample :
- Calculate the level of the signal : It can be a peak level as you did, but can also be RMS value on a few samples
- Calculate the "expected gain reduction" (timing not used here) depending on the input level (peak or RMS) and the threshold. If the input level is below threshold, the expected gain reduction is 0dB. If the input level is over threshold, then the expected output level over threshold is (input_level - threshold) / ratio, so the gain reduction is ( (input_level - threshold) - (input_level - threshold) / ratio ). In this way, with a ratio of 1, there is no reduction, and with an infinite ratio, there is a reduction of (input_level - threshold) which means everything above the threshold is send back to the threshold so the compressor act as a limiter
- Finally, there is all the timing stuff to do and state machine. The final goal is to calculate the "actual gain reduction" depending on the "expected gain reduction" from this sample, the "previous expected gain reduction", attack, hold and release, and previous sample values.
--- If the "expected gain reduction" is higher than the "previous sample expected gain reduction", it increase the limitation, the "actual gain reduction" = "previous sample actual gain reduction" + ("expected gain reduction" - "actual gain reduction from previous sample") / (FS * attack) => In that way, at each new sample, it goes a bit more close to the expected gain reduction, in an 1/exponential way. Also restart the Hold timer here.
--- If the "expected gain reduction" is lower or equal than "previous expected gain reduction", it reduces the limitation. If hold timer is not over, don't change "actual gain reduction". If hold timer is over, reduce the "actual gain reduction" as done in "attack" part, but using release time
- Multiply each sample with "actual gain reduction" (need to calculate from dB to linear)
I might have done some mistakes in the algorithm, but I am sure about the definition of the ratio
Great project for night movie mode! Would love to see the limiter follow up video!
Hey !
Today I looked over your excellent tutorial again.
Some remarks from an audio engineers perspective: in the original code your attack/release timing looks odd..30mS for attack is long, 20 +10 for release is really short.
In your real world example you did change the release timing by quite a bit, because it 'sounded horrible'..good!
Now for the fun bit:
There is actually 2 mistakes in the tx-rx complete callback routine as provide by CubeMX: 1. you have to repair the code to make the complete callback fire 2. the call back fires for both send and recieve DMA's so in fact you are running your interrupt code at twice the sampling speed
If you look close at your Audacity recording you can see for example, that your attack timing is half of the expected 30ms (which works out to a 'ok sounding' 15mS)
Anyway, keep up your good work!
Hi, thanks for your hints.
That with the complete-callback I already figured out and fixed this in the HAL libraries during my first video on IIR filters.
To be honest - that the callback is firing twice I was not aware. I checked that one time with the scope by toggling an IO with every callback and it was reasonable to me.
However - thanks I'll check it once again.
Can we perform stereo 31 band DSP based audio equalizer as well with the same hardware setup?
Hi, yet another great tutorial. But I am having severe issues with audio to video synchronization here. Wondering why I am apparently the only one experiencing this issue?
Latency? Can be used in real time an instrument filter?
hello, can you share me link of this version the root 2.0?
Thanks so much for this! My question, is de latency of this small enough to use in live settings?
Good work! I suppose that with LL drivers we can run this program on mini-board with stm32f103c8t6.It`s only needs a good 16bit ADC for stm32f103c8t6 .
Can you teach us to code c with stm 32 with port signal input and output
Great video as always.. one question.. Why is it necessary the attack and release times? why not only reduce the gain instantly?
adding attack allows you to shape the envelope of your signal such as allowing the initial tranient of a drum hit for "punch" and compressing the tail of the sound, which is shaped by the decay.
The audio and video sync is severely off (on the order of 1 minute or so). Any chance you could fix this and re-upload? Otherwise, this tutorial is great!
Brilliantly..!
Hey man love the videos, keep it up! Can you do a video on CANBUS protocol communication?
Well yes I already worked a lot with CAN communication. But my idea was to focus mainly on audio stuff here. But I keep it in my mind :)
Hi, thanks for your video. I am working on a university project using the stm32f407vet6 board and an inmp441 microphone (www.aliexpress.com/i/32962426410.html), the configuration I have for i2s seems not to be right, and I am confused. Set my plli2s to 96Mhz and in i2s set the frequency to 96khz, Data and frame format: 24 bits on 32 bits, the communication standard as MSB First (according to datasheet). but the dms uses a uint16 structure, so I assume that the 32bits is divided into 2 and I try to reconstruct the data but I can't do it, is it possible to help me understand it? For now I need to read the data from MEMs i2s and remove it by microcontroller DAC whether to apply dsp treatment. If you have an example I will appreciate it.
Please
You can help us to convert MATLAB code to VHDL
Much bettet compress sound stm32 is powerfulmthen Arduino