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
32 bits floatpoint to 32 bits integer  better audio?

 Experienced Member
 Posts: 114
 Joined: Fri Oct 01, 2010 7:47 pm

 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.

 Experienced Member
 Posts: 114
 Joined: Fri Oct 01, 2010 7:47 pm
Thanks, but what are biased numbers? :oops:
Wk
Wk

 Experienced Member
 Posts: 126
 Joined: Fri Feb 12, 2010 10:31 pm
This is where you use an unsigned integer to represent your numbers, but to allow for signed values you just subtract something (often 2^(n1) or 2^(n1)1) from the value stored in memory. So e.g. with an 8bit value you could have a range from 0 to 255 stored in memory, where 255 represents 128 (i.e. 255127), and 0 represents 127. The first Google hit explains this very nicely (from some sort of CS course notes): http://pages.cs.wisc.edu/~cs3541/beyon ... .flpt.htmlwilliamk wrote:Thanks, but what are biased numbers? :oops:
Wk
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 leftshifts can be done without tracking the sign bit?ale500 wrote:Using integers is going to be faster. Do not forget to use biased numbers so all operations are simpler.

 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
But I don't get why just using signed int would be slower compared to biased numbers?
Wk

 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.

 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 nonlinear 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 nonlinear 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 Ztransform  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.
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 nonlinear 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 nonlinear 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 Ztransform  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.

 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.
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.

 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.
You can read about limited cycles here:
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 IIRfilter, 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 TransposedDirectFormII implementation
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.
You can read about limited cycles here:
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 IIRfilter, 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 TransposedDirectFormII implementation
Probably not the most confused programmer anymore on the XCORE forum.