IIR EQ Design - Lowering CPU

[Rocko]

Dear all,

I would like to share with all forum members my latest IIR_EQ design which was written in SM (*.OSM).

I just found that I can neither post it on SynthMaker forum (is it locked for new messages??) neither to this forum (as it is *.OSM).
Any solution to this issue?

Rocko

[KG_is_back]

Most obvious way is to open it in flowstone and save it as .flp. I believe you can upload zip files, so you can jut zip it or change the abbreviation to .flp to "fool" the filter. Last way is to use external storage server like mediafire or dropbox and post a link. I remember times when SM forum was damaged and we had to upload all stuff that way

[Rocko]

Hi,

So, transferring a working project from SM to FS, is as simple as opening it in FS and saving it?
Any restriction or issues with such a transfer?

Is the SM forum locked for new comments?

Thanks,
Rocko

[KG_is_back]

Yes, it is as simple as that. However check if the schematic works properly in FS, because there were some minor changes in trigger and boolean system. I never noticed any issues though. Make sure when saving the file you save it with .fsm extension.

I do not know about SM forum, I visit it here and then, but I don't post there anymore (I don't even now if I remember the password anymore )

[Rocko]

Hi,

Here are the two files (Basic_EQ without graphics version and the IIR_engine itself):

https://www.hightail.com/download/elNJYlJSSU9TRTdMbjhUQw

If possible, please advice on lowering CPU and overall efficiency of code.

Any questions and guidance - I'd love to answer.

Feel free to use code parts.

[KG_is_back]

You can optimize the code of the filter engine in assembly just use this assembly code (assembler has its own primitive, that looks similar to code component):

Code: Select all

streamin in;
streamin b0;
streamin b1;
streamin b2;
streamin a1;
streamin a2;
streamout out;
float denorm=1e-9;
int absmask=2147483647;
float in1=0;
float in2=0;
float out2=0;

movaps xmm0,in;
movaps xmm1,in1;
movaps xmm2,in2;
mulps xmm2,b2;
movaps in2,xmm1;
mulps xmm1,b1;
movaps in1,xmm0;
mulps xmm0,b0;
addps xmm0,xmm1;
addps xmm0,xmm2; //xmm0=b0*in+b1*in1+b2*in2
movaps xmm3,out;
movaps xmm4,out2;
mulps xmm4,a2;
movaps out2,xmm3;
mulps xmm3,a1;
addps xmm3,xmm4;
subps xmm0,xmm3;
movaps xmm5,xmm0;
andps xmm5,absmask; //most optimal abs(xmm5)
cmpps xmm5,denorm,6;
andps xmm0,xmm5;
movaps out,xmm0;

note that A and B coeficients are opposite than the ones you use in your engine. It is only difference in naming conventions. what is in your schematics A0 is b0 in mine and so on.
Direct form 1 biquad filter can't probably get any faster than with above assembly code. Nevertheless the difference will be small and code that is there now is pretty fast anyway.

[Rocko]

Hi,

Thanks for the support and answers. Appreciated.

I had built another version with the suggested assembly code, and as you predicted, the difference in CPU is small.
I still will use the assembley code, tough.

This brings me to the next question:
Can I bring the CPU reading any lower? Why is it higher than other 'commercial' EQ (6 bands, stereophonic) on the market? Have I reached the SynthMaker limit (i.e. for a less demanding CPU reading, I must code it in C++ and use C++ tricks)?

And the next question
This version uses "green math" for knobs and Bi-quad calculations. I have another version with "blue code" for all b-quad calculations.
The "blue" version, is more CPU demanding but extremely stable. If the user "giggles" around the knobs, there are no audible artifacts.
Fro the green math code, the situation is the opposite.
My question is - can I expect to achieve full 100% stability (even at crazy "giggling" of knobs) with green code??
This will save me some more CPU.
Is "wireless" green code as stable as wired ?
For EQ's - one needs all the five bi-quads to change simultaneously to avoid clicks and pops. I doubt if "green" can make it 100% of the cases. Am I wrong?

Thanks for your comments,
I will upload the final version for all forum users to enjoy and use any parts of it.

Rocko

[KG_is_back]

You can use analyzer primitive to use code as if it was green. Is much faster then pure green and saves cpu compared to blue, because it calculates the stream code as one shot (it calculates only given number of samples).

Another way is to use 'hop' in the blue code version (look in the manual for more detail), to calculate the stuff only once in a while. Or even better in assembly it is possible to do do smart-hop that will do the calculations only when input has changed. That would be the most optimal choice however you will need little basic assembly skills to implement it (or send it to me and I will adjust it for you).

Here is how the smart hop looks like generaly:

Code: Select all

streamin in1;
streamin in2;
streamin in3;
//etc.

float PreviousInputSum=0;

stage2;

movaps xmm0,in1;
addps xmm0,in2;
addps xmm0,in3;
//... I believe you can see the pattern here - just sum all the inputs - it is unlikely that two inputs will change in exactly opposite directions of same amount;
movaps xmm1,PreviousInputSum;
subps xmm1,xmm0; //subtract the sum from previous sum
movaps PreviousInputSum,xmm0; //save the sum to previous sum
movd eax,xmm1;
cmp eax,0; //compare the difference between current and previous with zero
jz hopthecode; //if 0 skip the resto fo the code.
//////
//desired code here
//////
hopthecode:

[MyCo]

Here is an optimized version of the EQ. It uses only 3 Biquads instead of 6, but is still able to process all 6 by repacking the SSE channels. That's not a very common technic, but you'll find it in almost all highly optimized effects in SM/FS forum.

I've marked all changed modules with (MyCo), so you'll see what I've done. I've also replaced the filter biquad code by a little bit faster transposed form. For denormalization I just use the quickest method (add and subtract a tiny value). However I haven't converted it to assembler, although this would give a performance boost as well. You could hack the repacking module into assembler as well (using shufps), but this gets quite messy.

This version uses "green math" for knobs and Bi-quad calculations. I have another version with "blue code" for all b-quad calculations.
The "blue" version, is more CPU demanding but extremely stable. If the user "giggles" around the knobs, there are no audible artifacts.

When you pass green data that can change very fast (eg. knob turns) into streams, you should use "de-zippers". This smooths the green data to a continuos stream (basically a lowpass).

can I expect to achieve full 100% stability (even at crazy "giggling" of knobs) with green code??

Yes, "de-zipper" do that. However, green data is unpredictable. It comes into a stream when the CPU has time...

Is "wireless" green code as stable as wired ?

Yes, there's no difference.

For EQ's - one needs all the five bi-quads to change simultaneously to avoid clicks and pops. I doubt if "green" can make it 100% of the cases. Am I wrong?

Try the attached schematic.

[Rocko]

Hi,

Well, thank you all for the detailed answers and help.
I'm still digesting 'MyCo's answer...

referring to 'Kg_is_back' answer, i have went ahead and implemented two versions which are identical except the BiQuad calculation.
One is 'green math' calculation and the other is 'blue code' calculation based.
The 'blue code' version implements 'intelligent hop' as mentioned.

Comparing the results, I can see that the 'green math' version wins, as it shows (SLIGHTLY) lower CPU usage with a (MILD MORE) higher stability (when giggling like crazy the knobs).
The test is done on an intel i5 dual core laptop machine, running windows 7 32 bit and an old version of cubase 5.01.
I'm playing a *.wav file with 8 EQ's (all 8x6 bands are running) and measuring CPU on/off (by Cubase F12 CPU clock).

I still do not know what is "analyzer primitive" and could not find it in the SynthMaker's manual.
Could you point me to a written explanation of this method?

I'm simply sharing this data with other users of the forum...
Next step is to test "analyzer primitive" and implement 'MyCo's' suggestions !

Thank you all,
I love this forum