## 32 bits float-point to 32 bits integer - better audio?

Off topic discussions that do not fit into any of the above can go here. Please keep it clean and respectful.
williamk
Experienced Member
Posts: 114
Joined: Fri Oct 01, 2010 7:47 pm

### 32 bits float-point to 32 bits integer - better audio?

I was just wondering about a thing. All my current code uses float variables for processing audio. But from what I've read, a 32 bits integer will actually have better audio quality.

http://en.wikipedia.org/wiki/IBM_Floati ... chitecture

As a 32 bits float variable takes 24 bits for the data, and the rest for other things. So, when using it for +1 to -1, you are actually using 24 bits, right?

In any event, I did notice that some 32 bits integer audio devices do have very powerful audio, compared to 32 bits float computer software.

Just wondering, as I'm pretty sure I may be totally out of my way here... :oops: :lol:

Wk

Wusik Dot Com (http://www.Wusik.com)
William-K.com (http://www.William-K.com)
ale500
Respected Member
Posts: 259
Joined: Thu Sep 16, 2010 9:15 am
Using integers is going to be faster. Do not forget to use biased numbers so all operations are simpler.
williamk
Experienced Member
Posts: 114
Joined: Fri Oct 01, 2010 7:47 pm
Thanks, but what are biased numbers? :oops:

Wk
Wusik Dot Com (http://www.Wusik.com)
William-K.com (http://www.William-K.com)
bsmithyman
Experienced Member
Posts: 126
Joined: Fri Feb 12, 2010 10:31 pm
williamk wrote:Thanks, but what are biased numbers? :oops:

Wk
This is where you use an unsigned integer to represent your numbers, but to allow for signed values you just subtract something (often 2^(n-1) or 2^(n-1)-1) from the value stored in memory. So e.g. with an 8-bit value you could have a range from 0 to 255 stored in memory, where 255 represents 128 (i.e. 255-127), and 0 represents -127. The first Google hit explains this very nicely (from some sort of CS course notes): http://pages.cs.wisc.edu/~cs354-1/beyon ... .flpt.html
ale500 wrote:Using integers is going to be faster. Do not forget to use biased numbers so all operations are simpler.
The speed should be comparable to using signed integers though, right? All the instructions have signed equivalents IIRC. Simpler just because things like right- and left-shifts can be done without tracking the sign bit?
williamk
Experienced Member
Posts: 114
Joined: Fri Oct 01, 2010 7:47 pm
Ah, thanks, I get it now. I use that on some MIDI information already. ;-)

But I don't get why just using signed int would be slower compared to biased numbers?

Wk
Wusik Dot Com (http://www.Wusik.com)
William-K.com (http://www.William-K.com)
ale500
Respected Member
Posts: 259
Joined: Thu Sep 16, 2010 9:15 am
I meant simpler because you do not have to use floating point: you avoid conversions. And yes shifts account for easy adding of more channels.
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna
Very few Audio CODEC's can achieve 20 bits of ENOB http://en.wikipedia.org/wiki/ENOB or better.

But when it comes to processing the audio, the roundoff error may introduce problematic errors both with floats and integers. Floats may be easier, since they do not overflow (easily) in the calculations.

If we take a look at an IIR filter, it can be seen as a difference equation which are very close related to differential equations.
The solution to non-linear differential equation may have a chaotic behavior (as in Chaos Theory) where an extremely little difference in the initial state creates very different solution over time.
Furthermore, the chaotic behavior shows a lot of "patterns" which are far from random noise.

But wait! Isn't a digital IIR filter linear ? NO! Not at 100%
Each calculation ends with a truncation of the answer, which mathematically corresponds to an error that works as a non-linear process.

The roundoff error in the filter will create a roundoff noise, but that noise will not be a "white noise", and sometimes it may even be singing for you with tones changing over time, depending on the input signal.

Typically mathematical analysis of IIR filters are based on the Z-transform - but that only calculates the linear behavior of the filter, thus you will not see many clues of the spooky singing filters in such analasis.

Let's meditate over a plot of a Lorenz attractor :ugeek:

PS. Did you know that we can´t calculate the position of the planets far in the future (Even before Einstein made gravity even worse :mrgreen: )??
Newton's law of universal gravitation has a /r^2. If you find an analytic deterministic solution* for the position of 3 planet's or more over time - I will give you all my XMOS stuff for free! :lol: 8-)
* Series/Integral solution etc. are not permitted
DS.
Probably not the most confused programmer anymore on the XCORE forum.
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm
lilltroll,

Interesting thoughts about filters and rounding errors.

I guess somehow this is related to chaos theory BUT let's not get the issue of rounding/truncation errors mixed up with the idea of the sensitivity to initial conditions of chaotic systems.

In, for example, the classic case of the Mandlebrot set, the infinite complexity that arises is fundamental to the equations. It is not arising because of the random chatter of those least significant bits of your calculator. No matter how many bits you can use in your Mandlbrot calculation the shape of the set, in all it's complexity, is still there.

Of course sensitivity to initial conditions must show up as an effect of the number of bits used in the number representation. Having 33 bits may lead to a totally different result than having only 32. As you point out.

As for using floats or plain ints in such filter calculations I'm still not sure. As you say floats may be easier as they are unlikely to overflow. But shouldn't the writer of such a code be aware of the number range to be expected in the inputs, outputs and intermediate results? In which case a good choice of scaled integers in the calculations allows a greater resolution and hence less noisy results. Using floats is the lazy way out when you don't fully understand the calculation.
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna
In digital filters, it's more common to talk about "limited cycles"

Google for limited cycles, IIR filters, chaos

For an example you find:

In the chapter Noise, Chaos, Limit Cycles & the Jump
Phenomenon
you can for an example read:
Different initial conditions (recent signal history)
yield different limit cycles.

http://www.rane.com/pdf/ranenotes/Secon ... 0Right.pdf
You can also view Figure 4.

http://en.wikipedia.org/wiki/Limit_cycle
with a wider explanation here:
http://en.wikipedia.org/wiki/Attractor
and with a even wider explanation here:
http://en.wikipedia.org/wiki/Chaos_theory
Small differences in initial conditions (such as those due to rounding errors in numerical computation) yield widely diverging outcomes for chaotic systems

For fixed point IIR-filter, you MAC the B coeff prior the A coeff. That way the IIR filter will not overflow if you just have enough headroom for the accumulation of B coeff. e.g. using the Transposed-Direct-Form-II implementation
Probably not the most confused programmer anymore on the XCORE forum.