IIR EQ Design - Lowering CPU

[Rocko]

Hi,

Just went over 'MyCo's' solution and it is brilliant. Really nice coding !
It is beautiful...

With all these tips, CPU climbed down more than half !
Impressive.
My next goals are to finalize this code (move IIR calculation to assembly) add the graphical controls and FFT and dwelve into CPU testing again.

Thanks all !

[KG_is_back]

Analyzer treats any code connected to it as if it was green - an trigger calculates given number of samples and stores them into float array. Here's an example...

http://www.mediafire.com/download/yogs6 ... xample.osm

Also the analyzer outputs no. of CPU cycles per sample, so it is handy in optimization too.

[Rocko]

Hi,

I had noticed that Myco's had added a limiter to his module (a simple Min/Max based code, set to 0.99 as threshold).

I wonder when would one use such a limiter?
For a feedback design (like an IIR EQ) - I surely understand the need as one 'bad' sample can send the design to Armageddon.
Would you recommend using one in a compressor (no feedback loop)? Would you recommend using it in any audio DSP design?

Isn't 0.99 a value which is 'too far' from digital threshold, which can result in 'ruining' otherwise healthy peaks?

See this example in this (current) thread [answer number 8 by Myco's]:
http://flowstone.co.uk/support/viewtopic.php?f=4&t=2299

Best regards,
Rocko

[KG_is_back]

Hi,

I had noticed that Myco's had added a limiter to his module (a simple Min/Max based code, set to 0.99 as threshold).

I wonder when would one use such a limiter?
For a feedback design (like an IIR EQ) - I surely understand the need as one 'bad' sample can send the design to Armageddon.
Would you recommend using one in a compressor (no feedback loop)? Would you recommend using it in any audio DSP design?

Isn't 0.99 a value which is 'too far' from digital threshold, which can result in 'ruining' otherwise healthy peaks?

Rocko

Modern audio software uses 32bit float processing which supports values way above 1 ( =0dBFS) - there fore digital peak clipping doesn't happen in such programs even if you exceed the 0dBFS. However, if you hit your D-A converters with such output from your master (of your DAW) you will get clipping for sure. Setting the digital clipper to 0.99 (which is roughly -0.1dBFS ...so very close to digital threshold) may save your speakers and D-A converters from damage. Reason why we use 0.99 instead of 1 is to prevent intersample peaks.

As long as your software is meant to work in standard rage (for signals that peak under 0dBFS and are around -18RMS) the clipper will not affect the sound quality at all. It will distort the sound only when you get it to REDZONE which should be a sign for a user to pull it off.

[Rocko]

Hi,

Thanks for the explanation.

So, dividing the output by 2, means -6.02 [Db], which is usually rounded to (-6) [Db], correct?
for fixed point structure, this is a shift of a single bit.

So, the (well known) way to calculate dynamic range of a fixed point system:
16 bit --> 96 [Db]
24 bit --> 144 [Db]
32 bit --> 192 [Db]

From the provided explanation, this is only true for fixed point (Right??).
However, how do you calculate it for 32bit floating point?

Rocko

[KG_is_back]

From the provided explanation, this is only true for fixed point (Right??).However, how do you calculate it for 32bit floating point?

Yes, you are right. 32bit floating point number consists of a sign (+/- which is 1bit), 23bit mantissa which is basically (1+ (23bit integer)/(2^23)) - that means in <1,2) range and an exponent which is 2^(8bit integer). theoretically you can calculate the dynamic range from the exponent (minimal number of exponent is 2^-127 which is an order of 1000dB). If floating point number exponent reaches that point than the number behaves as fixed point number ( only mantissa matters) which adds another 144dB to the range (they are called denormals). However this dynamic range is computation-wise totally irrelevant, because the resolution of the number is order dependent. With each doubling of a value (increasing exponent by 1) you loose one (binary) digit in decimal places and gain one on the other end.
practical outcome is that you can perfectly represent 1.0000000 (23bit mantissa is roughly 8 decimal digits) and 1.0000000*1^-8. but if you add them the result will not be 1.00000001 (9 digits) - but it will be rounded to 1.0000000 (8 digits).
So Floating point numbers have practically infinite dynamic range on their own, but if you sum two float numbers, you loose data because the result is rounded to fit the number of digits. To improve floating point math, try to add values of similar order.

[Rocko]

Dear KG (an friends), thanks for the great explanation.

I have been reading abit more here: http://en.wikipedia.org/wiki/Binary32

So, the exponent is 8 bit, which means a number between [-127 : 128].
This means that the maximum exponent representation is (10^128) and minimum representation is (10^(-127)).

To verify I got it right, the dynamic range will be:
20*log[2^128)/(2^(-127)] = 20* log[5.86*10^(76)] = 1535 [Db]
To this value, one could add the 144 [Db] of mantissa which comes to --> 1679 [Db] of dynamic range.
Is this correct?

Bottom line for programming in F.S. or S.M.:
In this case, (just for an example) let's say I'm interested in doubling the input from a single audio channel, which can easily reach peak.
For floating point, I can simply write down:
out = in * 2;
While in fixed point I would have had to provide some sort of anti clipping mechanism, which will most probably not be linear... Right?

Rocko

[KG_is_back]

In this case, (just for an example) let's say I'm interested in doubling the input from a single audio channel, which can easily reach peak. For floating point, I can simply write down: out = in * 2;While in fixed point I would have had to provide some sort of anti clipping mechanism, which will most probably not be linear... Right?Rocko

Yes, that's right. However, in floating point format dynamic range (is so big that ) is most probably irrelevant - you can multiply numbers with millions or millionths with no precision loose. Here is a little schematic I've made, that you can play with. It's a floating point bit crusher. It can lower the bitsize of mantissa (by replacing last digits with 0s). If you set resolution to 0, the format will hold only values of 1*2^n ...you can see how the stairs in the format gent smaller as the number gets smaller. You probably will not see or hear any artifacts until you lover bitsize to 5 or 6 - there the distortion gets quite obvious. The number still has dynamic range of 1500dB (because the exponent is unaffected) but the mantissa carries the relevant resolution.

[Rocko]

Man this is great !
I do not know how to thank you enough... I find all this very interesting so SM (or FS) is a great experiment field to me.

Before I fire up the other PC (to check out the bit crusher), let me dig into theory/practice a tad more...

I'm interested in the 'format' rolling of the system.
Let's assume I run a 64 bit PC (windows 7/8) running a DAW (cuabse 5 for example) set to record audio at 24bit 44.1 KHz and run a synthmaker VST which is coded in 'blue math'.

How does the format go?

Is it this way:
DAW uses 24bit (floating point ??) to represent the audio 'word', based on a structure which can hold 64 bits (CPU).
The signal is then processed in 32 bit (floating point) environment within the VST ?

Thanks,
Rocko

[KG_is_back]

Man this is great !
I do not know how to thank you enough... I find all this very interesting so SM (or FS) is a great experiment field to me.

Before I fire up the other PC (to check out the bit crusher), let me dig into theory/practice a tad more...

I'm interested in the 'format' rolling of the system.
Let's assume I run a 64 bit PC (windows 7/8) running a DAW (cuabse 5 for example) set to record audio at 24bit 44.1 KHz and run a synthmaker VST which is coded in 'blue math'.

How does the format go?

Is it this way:
DAW uses 24bit (floating point ??) to represent the audio 'word', based on a structure which can hold 64 bits (CPU).
The signal is then processed in 32 bit (floating point) environment within the VST ?

Thanks,
Rocko

It depends on your daw. Most daws use 32float processing internally. When you load a wave (from a file or a soundcard input) it is converted to 32bit float (or whatever format your daw is using internally) and processed within your DAW. When DAW uses VST plugin it converts the audio to a format the plugin is using (in case of SM/FS plugins it is 32float, so no conversion is needed) and sends it to the VST. The VST processes the audio and sends it to DAW. The DAW converts the data back to the internal DAW format.
To schematically represent this:

soundcard/wavefile on disk [24bit] ->conversion to 32float(the format of the DAW)->[DAW internal processing ->conversion to 32float(or whatever format the VST is using)->VST->conversion back->DAW] ->conversion to output format -> soudcard output / mixdown wave file

BTW the actual computations are not affected by your system achitecture (32 or 64bit windows - they do computations in the same way). When you use variables in a programing language the processor actually doesn't call them by their names - he reserves place for that variable in your RAM and instead of using the variable name, he uses the position of the variable in your RAM. The position is called address and it is an integer of certain bitsize (32 or 64 depending on your platform). In single thread/program/process your processor can directly access 2^32 bytes in your RAM (which is roughly 2GB). That has become a problem on larger programs that handle audio or render video (they sometimes need more than 2GB) so modern processors have 64bit address which can index 2^64 bytes in your RAM (which is many times more than all RAMs on this planet can hold together). Either way, it has no affect on the computations that the processor does - it only affects how much RAM your processor can work with in one thread.