Re: EQ Algorithm, Low  shelf wrong!

S, the shelf slope parameter, should be in units of dB/octave. You can find complete detail on the equations Robert Bristow-Johnson's used to calculate these filters here.

I have branched this question into a new thread so that the thread topic won't change.

Thank you for your answer.

I read the " Cookbook formulae for audio EQ biquad filter coefficients ".

But the question still being here .

I cann't get the right result for calculating the Low shelf 5 coefficients.

I use the vc++6.0 to test, to calculate PEQ is OK.

But the LSEQ, HSEQ is not OK, I get the result is sonething like this:

b0: 6.87778

b1: -12.6453

b2: 5.77331

a1: -12.6479

a2: 6.14961

the input variables are: Fs=48000, boost= 20db, freq= 130hz, Q= 1.0, Slope= 0.1, gain = 0

The same config to the Sigma project got the result as follow:

b0: 1.05

b1: -1.9457

b2: 0.8883

a1: 1.9461

a2: -0.9462

Much different.

Who could validate the formulas ? For Low shelf, Hight shelf.

Or other information?

The appatch is the c file.

Thank you!

Today, I add the code to my MCU , to calculate the PEQ coefficents.

I found that it is not work.

Because the data I send to 1940 is not exacttly the same to the capture window data.

I mean, whether I use PC to calculate or MCU to calculate, (infact the data is the same), but different from the capture window data.

For example, I use PC (VC++6.0), to calculate the b0, the result is 1.0269048780039778, and the same config, the capture window data

is 1.0241494178772.

There is error, not exactly the same.

So, lead to the 5 bytes coefficent for b0 :

My calculation: 0x00, 0x83, 0x71, 0x9e

the capture window: 0x00, 0x83, 0x17, 0x54

My input and the configuration is : 20dB, 130Hz, Fs = 48000, Q = 1.0, gain = 0, For PEQ.

The probem is , my calculation data send to 1940 via spi, it is not work, the sound disappear.

The same code, replace the data with capture window data, send to 1940, sound is ok, worked.

Is there any example? Validated, if possible.

I must use the calculate method, because , as you see, the PEQ is at least 3 parameters, three-dimensional, can't use table.

Thank you.

MIchael

I suppose that you have one of 2 problems.

1) Using correct C type.

2) Rounding problems on calculation, (precision).

Regards

J.

At first, I use " float" type , just now , I use "double" of C type.

The result is the same.

You know , the PC is X86, and the Sigma DSP is also use PC to calculate, the data should be the same.

Again, my calculation: ( " double " type of C variables )

1.0269048780039778
-1.9997104300531479
0.97309512199602222
1.9997104300531479
-0.99730951219960218

the capture window's data:
1.0241494178772
-1.99434471130371
0.970484018325806
1.99434471130371
-0.994633436203003

Is there any more information on the aspects?

Thank you!

Hi Michael,

More important than the pure value of the coefficients is the frequency response of the calculated filter. Does it perform equally well with either coefficient set? Try simulating in a PC (Matlab/Scilab/Octave are handy here), then see the response on SigmaStudio directly, then simply try on your audio system!

Regards,

Jaime

Thank you!

I use the EVAL-AD1940AZ , the 1940 eval_board to test.

The eval board connect PC via the usb_board, to the Sigma Studio , is perform OK, the data is calculated by the Sigma Studio ,and see in the capture window, but I don't know how to calculate it like that.

Also, I remove the usb_board connecting to PC, the EVAL board side there is a port, I had checked the definiton of the pin, so the link 5 lines out

to my MCU board, and put into my MCU code, it work ok , the volume is calculate , control ok.

And the PEQ is also OK , while I use " looking for Table" method , I could hear the effect of the EQ.

But the " looking for Table" method , is not good for a " three dimension system", the table can't work ,when I change freq, dB, Q , and too much data to store.

So , use the calculating method.

The data I calculated are not excatly the same as the capture window.

When I send the data I calculated, with MCU ,via SPI port, the sound disappear, althought the data is not much deffer.

And , I use the capture window data to replace, it worked .

Thank you!

Hi Michael,

If I understood right, when you write "When I send the data I calculated, with MCU ,via SPI port, the sound disappear, althought the data is not much deffer. And, I use the capture window data to replace, it worked", you mean that you are able to take note of the values calculated from SigmaStudio in floating point format, recompile on your MCU, and download to SigmaDSP, and that in that case it works.

If so, it means:

- Your routine to convert from floating point to 5.23 is correct, this should not be a problem.

- You have problems in calculating the coefficients, and this could be any combination of wrong computation -algorithmic errors-, problematic library routines like for example for floating point emulation in your MCU, truncation/rounding errors in your MCU, and maybe other reasons.

Still, there are a number of things that you can test:

A. Sign check

1. Check the sign of A1 and A2 coefficients when downloading to SigmaDSP from YOUR calculated coefficients, see the documentation.

B. Correct coefficient calculation

1. Implement the coefficient calculation algorithm in a PC, compare against values calculated by SigmaStudio.

2. Re-compile the coefficient calculation algorithm in your MCU, and compare against the ones from the PC (see above).

3. In a PC environment, simulate the frequency response of the coefficients as calculated from the PC, from SigmaStudio and from your MCU.

C Correct download of coefficients

1. Use an SPI analyzer to capture the SPI frames that download the coefficients to SigmaDSP, from

1.1 SigmaStudio

1.2 Your MCU

2. Compare 1.1 and 1.2, to see if they are making sense, that means, that the 5.23 value, as calculated from your To523 routine, are valid. Feeding the routine with the floating point coefficients as calculated by the PC and by SigmaStudio, and seeing if they work when converted and downloaded from your MCU works, will also help you to find problems that you might have here.

Good luck!

Jaime

I almost forgot something VERY important:

You write LOW shelf, that means that it is very likely that your Fc is very small compared to Fs (say Fc = 15 Hz when sampling at Fs = 96 kHz, giving a normalized Fc = 0,00234375). Of so, chances are HIGH that the C libraries in your MCU for floating point calculation of coefficients do not have enough precision, and in that case you need 32-bit floating point libraries will not be enough, you will need 64-bit floating point to achieve the required precision.

Do this by using "long double" or equivalent datatype in your MCU code, and also be sure of enable those libraries in your MCU compiler toolchain (some settings might treat "long double"s as 32-bit values.

This can be found out by running the section "B. Correct coefficient calculation" from my previous post.

Happy debugging!

Jaime

Thank you, Jaime.

Not consider the MCU, just the PC to calculate .

The PC, I use VC++6.0 , to calculate, and I even use MATLAB software to calculated.

The follow:

my calculation: ( " double " type of C variables )

1.0269048780039778 // 0x00 0x83 0x71 0x9e
-1.9997104300531479 // 0xff 0x00 0x09 0x7d
0.97309512199602222 // 0x00 0x7c 0x8e 0x61
1.9997104300531479 // 0x00 0xff 0xf6 0x83
-0.99730951219960218 // 0xff 0x80 0x58 0x2a

the capture window's data:
1.0241494178772 // 0x00 0x83 0x17 0x54
-1.99434471130371 // 0xff 0x00 0xb9 0x50
0.970484018325806 // 0x0 0x7c 0x38 0xd2
1.99434471130371 // 0x00 0xff 0x46 0xb0
-0.994633436203003 // 0xff 0x80 0xaf 0xda

The same config and input : Fs = 48000, freq= 130hz, boost = 20, Q = 1.0, gain = 0;

The data I calculated ,send it , the EVAL board 's sound diappear, the capture window's data is ok to perform the effect.

Just use the MCU to send , the MCU not calculated when I test this. The 20 bytes data of 5 coeffients.

I mean, I first use the PC calculated , then , if the data is the same to the capture window's , I put the code to MCU.

But , the "first step" not yet succeed, I just use MCU to send the result of PC calculated to 1940, it not worked.

But use MCU to send the the capture window's data to 1940, OK, the EQ effect is hear.

My problem is that, I can't get the same result as the capture window's data , and it even doesn't work, sound disappear.

Thank you!

https://ez.analog.com/cfs-file/__key/communityserver-discussions-components-files/396/8475.c29b69bcdb4b3c62377c161e59b8db9e.bin

May be the problem is here:

See this formula: A = 10^(boost/40); the "boost", I just think it is the dB value , 20dB ? If I set the General (2nd-Order) block in the Sigma Studo as above.

No, I see the boost value there is a range of -200 ~ 200, and the Value can set 100.00, 200.00, or others, is this value the "boost" directly?

Should it need do some conversion ? For example : linedata ?

And the Shelf EQ is the same problem, the formula:

sin(ω0)/2 * sqrt((A + 1/A)*(1/S - 1) + 2) (type: Shelving), the 'S' , the slope, should not be '0', but the General (2nd-Order) block can set it to '0' .

And for Shelf EQ ,there is " Scale gain ", may be should do conversion.

So, how to do conversion?

The frequency , Q value, Gain, Scale gain should convert for the General (2nd-Order) block ?

Urgency, really!

Thank you!

https://ez.analog.com/cfs-file/__key/communityserver-discussions-components-files/396/5826.9103473c22de6c280836dff0a3227bfc.bin

Hello.

I found that, before, I didn't divide by "a0".

I calculated the a0, and other 5 coefficients divide by a0, the result is almost the same as the capture window.

As follow:

PEQ:

a0 = 1 + alpha/A;

coeffi[0] = ((1 + alpha*A) * gainLinear)/a0; //b0

coeffi[1] = (-(2.0 * cos(w0)) * gainLinear)/a0; //b1

coeffi[2] = ((1 - alpha*A) * gainLinear)/a0; //b2

coeffi[3]= (-(-2.0 * cos(w0)))/a0; //a1

coeffi[4] = (-(1 - alpha/A))/a0; // a2

But, should I convert the data : boost, freq, shelf_slope , gain?

Thank you!

Hi Michael,

I am glad that you are finding some flawes, at least have something to fix! Some points you should remember when implementing those filters, and in general for DSP stuff:

- Usually in DSP implementations the coefficients are nomalized by dividing over a0, that way the internal implementation has one less multiplication to run, which means saving clock cycles as well as memory.

- Also, normally you have to invert the sign from the results of the calculations of filter design programs (or equations) for coefficients a1 and a2 to match the internal implementation of the algorithm.

These are all issues documented in the SStudio help system, please make sure of reading it in order to be aware of those -and maybe other- details.

Kindest regards,

JaaC

Thank you, Jaime.

My English is not good.

And the Studio help system, I dont't think it is enough details.

For example, It say: " For each of these three filters, all the coefficients are divided by a0." , why not said:"all the coefficients should be divided by a0, and then send to the DSP , " and not enough examples.

Ha ha , my problem have already got solved.

Thank you!

Michael,

I'm glad to hear that you got your coefficient problems solved.We will look into what might need to be updated in the SigmaStudio documentation.

Thanks to everyone else here who helped to solve this issue!

Hi Michael,

I am glad that this got your issue solved. Sometimes it is necessary to think somehow out of the box and try other approaches, which might show where the flaws are.

Regards,

JaaC

Hi Jerald,

SigmaStudio is a great tool, and coupled with SigmaDSP family of processors makes one of the most friendly, easy to use and powerful DSP platforms for audio applications in the market. I have been using it throughout the years, since it was based on some OrCAD tools to do the signal flow layout (AD1953 and AD1954 components were at that time available).

I have seen that with some releases the documentation is better than with others, and somehow it makes no sense; as a user, one expects documentation to be as rock solid as the chips and the tool itself, and become better as chips and tools mature; although the tool is intuitive, there are very specific implementation details that if one does not know about them, simply renders the tool useless. So, the suggestion, and I think I would be followed by many fellow engineers out there, is to have better documentation, one that one can rely on. Excluding this, just thumbs up and keep the good job!

JaaC