Author Topic: Help! Struggling. DSP Code.  (Read 501 times)

0 Members and 1 Guest are viewing this topic.

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4038
  • Country: gb
Help! Struggling. DSP Code.
« on: December 05, 2022, 12:17:56 pm »
I switch from being enraged by this and then feeling humbled and helpless.

Requirement.  A jelly bean 5 band parametric audio equalizer on an ARM DSP enabled MCU.

Research so far has been heavily dominated by calculus.  99% of information seems to come from either a predominantly mathematical approach or a predominantly electrical engineering approach.  Both approach it mathematically in mathematical language, symbols, frameworks and expressions.  I do understand it IS a mathematical concept/process and thus it is best described in that language.  It's just that I don't speak that language.  So I can't understand what they are saying.  I can follow along, often I even go "Ohhh, ahh!  Okay.", then they show the script, the equations and start explaining it in terms of eulars approximation and z transform and ...  gibberish.   The most frustrating thing is after sitting through a LOT of these, it turns out NOBODY DOES IT THAT WAY ANYWAY ANYMORE!  Arggh!!!!  Why?  Why do they waste hours and hours of time on concepts that are not used and then tell you, "Oh wait... so everyone actually does it with biquad cascades.  Those are a different thing!", I swear my blood boiled.

Coming for a software engineering background I think I have found the front-lines in this are not at all civil or amicable. The two domains do not appear to mix well.

The electrical engineers, much like the mathematicians will invariably want to re-reduce the problem back to it's most theoretical form and re-calculate it for the specific application.  Rederive everything.  They are absolutely 100% fine with redoing ALL the calculations from scratch for every slight variation.  I get it.  That is going to result in the best possible fit and the lowest BOM.  It's the best way to avoid "Oopssies". 

Software engineers on the other hand are busy running around wiping everyones white boards of equations and sticking a black box calculator to the wall.  The entire ethos is to NEVER repeat anything.  If you have to sit and calculate the filter coefficients for a SINGLE filter, you will take months, not because it takes you months to do the calculation, but because as a software engineer you want to make ABSOLUTELY god damn SURE you NEVER, EVER need to do it again.

You can almost literally see the line drawn with a barbed wire fence in larger projects.  "HERE BE DRAGONS" and underneath it is.... mathematical gibberish.  It's MathLab generated garbage that explains nothing of what it does or why.  It's 100% obfuscated.  Usually including 8 kilobytes of lookup tables and instead of a python script in the utils/ folder to generate it, there are links to MathLab deriviative plugins and code generators and a dozen references to different "Named mathematician processes and transforms".

So... can't you just lift that code and re-use it?  Hell no.  The layer above it has been partially infected to with "magic numbers" and single letter variables/symbols everywhere.  Clearly that layers coders had to beg the maths people to explain in really simple terms WTAF was going on and probably in frustration said, "Here, you call your own garbage" and stormed off for more coffee.

Unfortunately, you can't, usually just lift these examples, but 99 times out of 100 when examining them you find they have been tweaked, tailored, hardcoded and locked in on a rather oddly bespoke set of bands or gain steps in order to make it more efficient (to flex the power the master wizard mathematician).

I can understand what a filter is.  I can understand what different types of filter are.  I can understand the parameters to those filters.   I can understand that given those parameters some wizardy of mathematics happens and the resulting digital waveform has been filtered such as to meet those parameters.  I wish to care not how.

If I call:

httpsConnection.postSecure(sslCert, stuff);

I do not want to have to sit through a lecture on public private key cryptography to derive the 4096 bit prime number coefficients for the 32bit floating point decimal representation precision of the CPU.  I just want to send some data. 

Help!
« Last Edit: December 05, 2022, 12:19:30 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4038
  • Country: gb
Re: Help! Struggling. DSP Code.
« Reply #1 on: December 05, 2022, 12:56:20 pm »
This is about the closest I have found to what I'm after:
https://github.com/dimtass/DSP-Cpp-filters/tree/master/lib

I get that calculating the coefficients for every EQ change will be heavy, but seriously that is in the "Human time domain" and ...  MCUs are cheap if you don't need to make 1000s and dont have an accountant.  I just got to work out how to reuse this in an embedded architecture.  At least it's functions speak English and EQ domain terms like Cut off, centre frequency, gain, bandwidth/Q and not x of n . omega y ...  I have to port it to ARM DSP biquads as well though. 
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Online macboy

  • Super Contributor
  • ***
  • Posts: 2254
  • Country: ca
Re: Help! Struggling. DSP Code.
« Reply #2 on: December 06, 2022, 01:27:40 am »
Sure there is a lot of theory and math behind how IIR filters work. But it boils down to implementing with biquads which are pretty simple. The calculations to derive the filter coefficients in real time need not be heavy. I implemented an eq controlled by an 8 bit PIC and was able to calculate biquad coefficients in 32 bit floating point, from frequency, Q, and gain in just a few ms. That's on an 8bit'er without hardware multiply. On a more capable 32b MCU it becomes trivial.

You need two basic things, code for the DSP to implement a generic biquad, and a way to calculate the coefficients for the biquad on your host MCU . The biquad code is simple but you should also be able to find many examples. Find a cookbook of equations to calculate the coefficients; I had little trouble finding them 15 years ago. I sure as heck didn't derive them myself from the theory. I don't think I could.
 
The following users thanked this post: paulca, RJSV


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf