• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

STM32 based DSP/EQ

IAtaman

Major Contributor
Forum Donor
Joined
Mar 29, 2021
Messages
2,515
Likes
4,539
Well, I wanted a new pet project for a while and fiddling with the eqMac (and hating it), I thought, why not build one yourself! I am aware there are quite a lot of RPi4 based solutions out there, but 1. Pi4 is very hard to source even if you are willing to pay win11 mini PC prices for it, 2. I love playing with embedded systems 3. downloading software from the internet and installing is hardly a pet project, so I decided I want to build one based on widely available ST32 platform. Has anyone any experience with it?
 
Why not something actually purpose build? ADAU1701/1501 boards are cheap and easy to get. They have vastly more DSP processing power and are tailor made for audio. Add an ESP32 and a bit of firmware, and you can wirelessly connect it to SigmaStudio.
 
Mainly because I did not know about them :) Thanks for the tip, had a quick look, definitely looks like they would make the job easier. I do like the flexibility of the MCU though. I think I will order both and tinker.
 
See the Parks Audio Puffin for an example, using one to apply various phono eq options, declicking and more. The spdif diy mod page shows the STM32 eval board it uses internally. IIRC that's using an F4 with a proper I2S interface father than abusing the SPI interface on the more common F103 boards, but it's a while since I looked. I didn't investigate the pin they use for the spdif output to see if it was special in any way.
I don't know if you're interested in the Pi Pico at all, but its programmable I/O examples include spdif. I don't know the status of the UAC2 support in its USB library.
 
Funny you say that... just a quick cap of what I was working on. The UV meter was the "play" tonight. I was testing the debug UART logging setup and at the same time testing overloading the debug UART would not upset the audio... with some interrupt priority tweaks. On UART at 115200 baud the UV meter runs at about 6fps. The data feed it is running about 12Hz. It's overloaded. The audio is unaffected.
 

Attachments

  • vu_meter2.png
    vu_meter2.png
    410.3 KB · Views: 139
Last edited:
The F411 boards have 4 I2S I believe, might be 6. However they have enough CPU power to run maybe 1 or 2 IIR filters.

The chips I gravitated towards are the H7s. The H743 and H750 are available in module form from Aliexpress. Expensive at around £35 these days. It has an ARM M7 Core @480MHz with a double precision float point unit and DSP extension hardware. The difference, asides price is the 743 has 2Mb of FLASH where as the 750 only has 128kb flash. The 750 is fine for audio. You don't need flash for media.

A few notes. The H7s can be a bit fiddly. They are more complex than the F4s, multiple memory segments, multiple memory and DMA buses, multiple bus matrixes. If STMs are not yet your thing, it might be worth starting with an F4 where everthing is flat. The advantage other than the power is the 4xSAI peripherals. They are like I2S++, awesome hardware. each of the 4 has 2 sub blocks, giving you a theoretical 8 IO + the 3 I2S + SPDIF. 8 sample FIFO on each, which is more than enough buffer to process. I actually use 2 samples as the distortion potential is dropped to close to 0. No buffers, no latency, no DMA.

The SAI blocks also synchonise with each other when required. Meaning if you have 2 outputs, you can make the second one a slave to the first and that only introduces a single additional pin, as the clocks are shared.

DSP IC route. I looked briefly. The ONLY thing making them even practical to conceive of using is the PC based GUIs to set them up and tweak them. DSPs without a GUI tool will take you months and months of research into datasheets and programming registers.

Just be careful the term DSP is used to refer to a wide range of devices. Most of the cheap, simple, DSPs are really just "Hifi in a chip". You'll find these ADUs in most car hifis, a lot of home HiFis, TVs etc. Because "HiFi on a chip". They will be fine. However you will end up doing things that particular DSPs way. If it supports what you want, bonus, if it doesn't tough.

You will of course have all the other things to consider. Like front ends, rear ends, GUIs, controls, a screen. A PCB and a case.

The STM32 you get to do what you like. Mine is targeting 3 mixed inputs. 2 or 3 simultaneous outputs. I had it running 7 IIR stereo peak filters and ran out of CPU. Then I optimized the code and it now runs 5 peak bands on one EQ channel and 3 peak bands on a second (two different outputs). The "duty cycle" for the audio processing is around 21% at the moment. Hence seeing how much I can throw on top and keep it stable in the previous post.
 
<A lot of very useful information/>

Thank you very much for this, it was super helpful.

Development board I ordered is has an F407 on board. I decided to go with that exactly due to reasons you have outlined.

The application I have in mind is a 10 band PEQ sitting between the computer and the DAC that I can configure via a web based interface. If I can add a VU meter to it with a small OLED screen, that would be the cherry on the cake. I have no idea whether the MCU would be able to cope with what I have in mind or if I can complete such a project, but I am willing to give it a try and with 2 USB OTG and 2 full duplex I2C I thought at least the communication part would be enough and flat memory would make life easier as I de-oxidize. My plan is to play around with it to see what I can get done with it and maybe move to a more powerful H series chip if all works well.
 
Ah. USB. It is the "go to" I know. It's also a right pain in the ***. The USB async stuff can be avoided if you are careful, but the STM32 USB drivers are a bit of a badlands. Some people are fine with them, I never got alone. I ended up moving the USB stuff to hardware. Either cheap 48k/16bit USB DACs which support I2S output, such as the PCM2706 modules on Ali, or the more expensive FPGA based "audiophile" USB bridges (Anamero or clones). That way you don't need to deal with the USB stuff at all, you get an I2S stream instead with all the async/isosync stuff taken care of.

The F407 is 230Mhz? Might be 180. It might do 10 band stereo parametric EQ for a single stereo channel, but it will take full optimization and probably force you into using the ARM Math DSP library functions, limiting your options.

If you follow the realtime sample by sample processing model it is easy to introduce inherent resampling. The worst that happens when you run out of CPU is instead of 48K, you get 24K.... or some other random sample rate. Depends on how young you are as to whether you notice. In honesty, I noticed. Only just, had a suspicious, something sounded off. Turns out it was running at 24k. Proving I can't hear much above 12K anyway. The "something sounds off" is more likely aliasing distortion in the downsample.

If you have the board, have a go at the examples for USB Audio UAC to I2S. You can use any I2S DAC, but the little PCM5102 modules from Amazon or Ali for £10 are pretty bullet proof and support some pretty HQ rates.

When you get tired of playing silly buggers with USB, the PCM2706 USB Bridges will make all that go away, leaving you with only it's I2S clocks to care about.

Full Duplex I2S, it's not something I have really found a use for. It's really only there because the SPI peripheral is usually setup that way for a round-robin bus. If you want bidirectional audio for both playback and record over USB, that might introduce a whole different set of challenges.
 
A few links from my recent orders, if you do explore the MCU route.

STM32H7s - prices are currently highly volatile.

"Baller" audiophile USB bridge, supports DSD512 etc.

PCM5102 DAC

Optical bridges - I2S->OPT OPT->I2S I2S->SPDIF.... etc. etc.

Bluetooth 5.0 audio I2S Rx module

Useful tools would include a logic analyser and ideally a scope.
 
I just got my first "dev" prototype PCB for this setup.

Still a long way to go. This is not a final board, it was just to get it off of breadboards which were driving me nuts with dodgy connections.

Lots of software dev to do and another whole board for the screen and knobs.

Still plenty of hardware nice to haves as well missing on this board.
 

Attachments

  • IMG_20230313_220118978_HDR.jpg
    IMG_20230313_220118978_HDR.jpg
    392.7 KB · Views: 159
Still plenty of hardware nice to haves as well missing on this board.
Very nice setup you got going on there. I am still waiting for the F4 dev board to be delivered.

Those two are the optical bridges if I am not mistaken. The other board, is that the USB bridge?
 
Looks to me like one optical/coax to i2s bridge at the top, and a pair of PCM5102 DAC boards below.
 
Yep. One optical/coax I2S bridge. Two PCM5102A DACs and an STM32H750 MCU.

Additional I2S headers for a USB I2S/DSD Bridge and a smaller PCM2706 "driverless" USB bridge.

2 WS2812b RGB LEDs.... because I have a roll of them and they are cool for status lights, clip lights, error lights etc.

2 x UART headers. 1 x Bidirectional SPI header. These give me options for the UI / Display connections.

The PCB is mostly just an interconnect. It has way too much capacitance because I had 220uF Kemets in a bag accidentally purchased and never used because they are only 6.3V. Perfect for a 3.3V circuit though! I even went all out on dual ground planes and via gaurds for all the high frequency I2S lines.

The power supply was thrown on in a corner, the AS1117 was literally stolen off another module. It does not provide any filtering. The PCM5102s don't have a dedicated analog ground either, so if you connect the board to a noisy USB power supply... you get noisy audio. Which is one large part of the "not done yet" situation. The PSU I will design and test soon, now I have a stable core dev board.

Eventually things like the PCM5102s and PCM2706 will go on the PCB are bare metal. The optical and USB bridges I will probably retain in module form, but secure properly :)
 
One of the UARTs is active and supports either a commandline for setting the EQ parameters or a funny terminal VU meter toy I did when I was bored.
 
One of the UARTs is active and supports either a commandline for setting the EQ parameters or a funny terminal VU meter toy I did when I was bored.
I got gear envy.
 
eqMac (and hating it)
FWIW, did you give SoundSource a try? Has headphone/autoeq profiles from multiple sources, supports importation of PEQ profiles from text files, VST/AU support (I use it with crave eq and kirchhoff as well as rnnoise for voice calls), adds a ton of audio functionality to the system.
 
FWIW, did you give SoundSource a try? Has headphone/autoeq profiles from multiple sources, supports importation of PEQ profiles from text files, VST/AU support (I use it with crave eq and kirchhoff as well as rnnoise for voice calls), adds a ton of audio functionality to the system.
No I did not. Got an RME ADI-2 and has been using that instead mostly. I am checking out their website now, will try it tomorrow when I am on the Mac. Thanks for the suggestion. Project is still a go though :)
 
FWIW, did you give SoundSource a try? Has headphone/autoeq profiles from multiple sources, supports importation of PEQ profiles from text files, VST/AU support (I use it with crave eq and kirchhoff as well as rnnoise for voice calls), adds a ton of audio functionality to the system.
I am on the Mac now and checked SoundSource and remembered that I have downloaded it but did not use it as it required me to change the global security policy of the computer which did not sound right to me, hence I have given up.
 
I am on the Mac now and checked SoundSource and remembered that I have downloaded it but did not use it as it required me to change the global security policy of the computer which did not sound right to me, hence I have given up.
 
Thank you, yes I have seen and read it before. I am a MS guy since 286 era and am realatively new to Mac. Basically they are saying, as every software vendor would say, "that's fine, yeah, totally ok, go ahead and change it" which was not really exuding confidence , so I checked Apple support which reads:

Kexts have the same privileges as the kernel, and thus any vulnerabilities in third-party kexts can lead to full operating system compromise.

Same privileges as kernel is the part I gave up. Maybe you know more than I do - do you think it is fine?
 
Back
Top Bottom