Forums

Audio processing -- fixed or floating point?

Started by john December 18, 2005
I just watched a video on Microsoft's Channel 9 site about the new
audio processing code that they are putting in Windows Vista (the next
version):

http://channel9.msdn.com/Showpost.aspx?postid=145665

They are changing from an "int16 pipeline" to a "float32 pipeline".
They assert that using floating point for audio processing yields far
better fidelity than int16, and also point out that on a Pentium,
floating point is efficient (the old int16 code dates back to when they
supported 486 chips with no floating point).

Not being an audio person, I was wondering what some of the experts
here would say about that assertion. Is it really always better to use
floating point for audio processing such as SRC, mixing, eq, etc?

John

the 32-bit float carries all of the information of a 16-bit int and
even more.  of course it  will sound better (at the expense of twice
the memory in the pipeling.

the issue that us audio guys argue about is given a particular word
width of N bits.  which sounds better?  an N bit float (how are N bits
divided into exponent and mantissa?) or fixed point?

r b-j

On Sun, 18 Dec 2005 04:32:55 -0800, john wrote:

> I just watched a video on Microsoft's Channel 9 site about the new > audio processing code that they are putting in Windows Vista (the next > version): > > http://channel9.msdn.com/Showpost.aspx?postid=145665 > > They are changing from an "int16 pipeline" to a "float32 pipeline". > They assert that using floating point for audio processing yields far > better fidelity than int16, and also point out that on a Pentium, > floating point is efficient (the old int16 code dates back to when they > supported 486 chips with no floating point).
PCs pretty much since the P6 core (Pentium 2/3, M, 4) have had better floating point performance than integer. There's whole extra chunks of hardware to do that work, leaving the integer part to get on with sorting out addresses and conditional code. Since the SIMD instruction sets were introduced (3DNow!, SSE{,2,3}) floating point has just become comparatively stronger. This is mostly in support of video games, where smallish floating point numbers seem to be essential for geometry computation. Audio gets a nice free ride as a result. When the SIMD extensions first came out, the heavy number crunching guys complained, because 32-bit floats aren't actually terribly useful for big maths problems. Now (SSE3) there's SIMD double precision maths, so everyone's happy. So yes: efficient. Better audio quality? Well, usually. that's actually a bit of a curly question. When 16-bit integers are used in audio, the results of products are usually accumulated in (integer) words that are 32 (or, preferably, more) bits wide. That means that if you only use 32-bit floating point numbers for your calculations, you might actually be losing seven or eight LSBs that an integer computation would preserve (a 32-bit float has about 25 bits of mantissa). Are those bits significant, and do they contribute to significant noise floors? Well, that's pretty much impossible to say in general, but the noise analysis is much more complicated in floating point than it is in integer, anyway. If you're going to be dithering down to 16 bits for final output chances are that will mask any introduced computation noise. If you're going to output 24-bit digital data somehow, then maybe you need to be careful with those floats. If you only have 32-bit floats, you might have more trouble building a very low frequency IIR filter than someone who can use double-precision (or higher) fixed point arithmetic.
> Not being an audio person, I was wondering what some of the experts here > would say about that assertion. Is it really always better to use > floating point for audio processing such as SRC, mixing, eq, etc?
Always? No, it depends on the situation. In a PC? Probably. In a portable device? Probably not: floating point computation (particularly the "IEEE-754 compliant" variety) requires more transistors and so consumes more power than broadly equivalent integer computation. So for now, most portable music devices use fixed point, and many wall-powered devices use floating point, but some of these use fixed point too, perhaps for cost reasons, perhaps for historical reasons. FWIW Apple's "Audio Units" system in MacOS X is floating point, and AltiVec is good at 32-bit floats (but not doubles). Cheers, -- Andrew

john wrote:

> I just watched a video on Microsoft's Channel 9 site about the new > audio processing code that they are putting in Windows Vista (the next > version): > > http://channel9.msdn.com/Showpost.aspx?postid=145665 > > They are changing from an "int16 pipeline" to a "float32 pipeline". > They assert that using floating point for audio processing yields far > better fidelity than int16, and also point out that on a Pentium, > floating point is efficient (the old int16 code dates back to when they > supported 486 chips with no floating point). > > Not being an audio person, I was wondering what some of the experts > here would say about that assertion. Is it really always better to use > floating point for audio processing such as SRC, mixing, eq, etc? >
Floating point greatly simplifies the development. Also the floating point is indeed very efficient on the P5+ CPUs. They do not do much of audio processing in Windows, so I doubt if there is going to be any noticeable difference. Technically speaking, the single precision IEEE-754 float accuracy may not be sufficient for the certain aspects of audio processing. The 32-bit int may produce better results. Specifically, the float point will cause problems with IIR filters: limit cycle oscillations and noise. The bottom line is: "The chicken laid an egg, but she cackles like she laid a planet". I don't expect any great improvements from the use of the floating point and I don't consider it as a big deal at all. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Vladimir Vassilevsky wrote:
> john wrote: > > > I just watched a video on Microsoft's Channel 9 site about the new > > audio processing code that they are putting in Windows Vista (the next > > version): > > > > http://channel9.msdn.com/Showpost.aspx?postid=145665 > > > > They are changing from an "int16 pipeline" to a "float32 pipeline". > > They assert that using floating point for audio processing yields far > > better fidelity than int16, and also point out that on a Pentium, > > floating point is efficient (the old int16 code dates back to when they > > supported 486 chips with no floating point). > > > > Not being an audio person, I was wondering what some of the experts > > here would say about that assertion. Is it really always better to use > > floating point for audio processing such as SRC, mixing, eq, etc? > > > > Floating point greatly simplifies the development. Also the floating > point is indeed very efficient on the P5+ CPUs. They do not do much of > audio processing in Windows, so I doubt if there is going to be any > noticeable difference. > > Technically speaking, the single precision IEEE-754 float accuracy may > not be sufficient for the certain aspects of audio processing. The > 32-bit int may produce better results. > > Specifically, the float point will cause problems with IIR filters: > limit cycle oscillations and noise. > > The bottom line is: "The chicken laid an egg, but she cackles like she > laid a planet". I don't expect any great improvements from the use of > the floating point and I don't consider it as a big deal at all. >
Interesting. In the video the MS guys leave the the impression that the fidelity improvements will mainly be in situations where the legacy integer solution was difficult to properly implement in the first place. John
Vladimir Vassilevsky wrote:

> > > john wrote: > >> I just watched a video on Microsoft's Channel 9 site about the new >> audio processing code that they are putting in Windows Vista (the next >> version): >> >> http://channel9.msdn.com/Showpost.aspx?postid=145665 >> >> They are changing from an "int16 pipeline" to a "float32 pipeline". >> They assert that using floating point for audio processing yields far >> better fidelity than int16, and also point out that on a Pentium, >> floating point is efficient (the old int16 code dates back to when they >> supported 486 chips with no floating point). >> >> Not being an audio person, I was wondering what some of the experts >> here would say about that assertion. Is it really always better to use >> floating point for audio processing such as SRC, mixing, eq, etc? >> > > Floating point greatly simplifies the development. Also the floating > point is indeed very efficient on the P5+ CPUs. They do not do much of > audio processing in Windows, so I doubt if there is going to be any > noticeable difference. > > Technically speaking, the single precision IEEE-754 float accuracy may > not be sufficient for the certain aspects of audio processing. The > 32-bit int may produce better results. > > Specifically, the float point will cause problems with IIR filters: > limit cycle oscillations and noise. > > The bottom line is: "The chicken laid an egg, but she cackles like she > laid a planet". I don't expect any great improvements from the use of > the floating point and I don't consider it as a big deal at all. > > Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.com
There is something of a tradeoff when using floating point for DSP on a Pentium or Athlon. As everyone else has said, basically floating point performance blows away integer performance on modern processors. As long as you are careful about floating to integer conversion (use the C99 rint() function) the conversions can be quick and painless. However, there is one snag with floats on Pentiums and Athlons - denormalisation on underflow. When a float gets really close to zero, and will no longer normalise properly, performance is really really terrible. The situation is treated as an exception, and handled by complex exception processing. People try nudging the numbers to avoid this. However, strict avoidance requires comparisons and branching, which means possible pipeline stalls. Its all very messy. Try Googling for something line "dsp float denormalize pentium" and you should hit a wealth of discussion on the topic. The frequency with which most code hits the problem is small, but the effect is big enough to wreck tight real-time operation. Regards, Steve
Hi Vladimir,

Vladimir Vassilevsky napisa�(a):
(...)
> Technically speaking, the single precision IEEE-754 float accuracy may > not be sufficient for the certain aspects of audio processing. The > 32-bit int may produce better results.
thats interesting for me. I have problems with IIR filter stability (6th order Butterworth highpass at 20 Hz and 48ksps sampling) on Motorola DSP56300 (24-bit fixed point). Plan to change platform to SHARC Melody, but it seems that should still use fixed point representation ? ! Best regards Roman Rumian

Roman Rumian wrote:

>> Technically speaking, the single precision IEEE-754 float accuracy may >> not be sufficient for the certain aspects of audio processing. The >> 32-bit int may produce better results. > > > thats interesting for me. I have problems with IIR filter stability (6th > order Butterworth highpass at 20 Hz and 48ksps sampling) on Motorola > DSP56300 (24-bit fixed point).
It is quite obvious that is not possible to straightforward implement any good IIR HPF with Fc = 20Hz Fsa = 48kHz using 24-bit precision. You have to apply noise shaping or better use double precision ariphmetics.
> Plan to change platform to SHARC Melody, > but it seems that should still use fixed point representation ? !
The IEEE-754 4-byte float has only 25 bits of precision, so it is not going to help any. Indeed if you do MACs in float, it is going to be much worse then using int 56-bit accumulation. However SHARC native is 40-bit floating point which gives you extra 8 bits, which could be barely sufficient for what you are trying to do. SHARC supports for 32 bit integer MACs with 80 bit accumulation. This is the way to go. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Vladimir Vassilevsky wrote:

> > The IEEE-754 4-byte float has only 25 bits of precision, so it is not > going to help any.
it will an improvement over fixed point for low-level signals.
> Indeed if you do MACs in float, it is going to be > much worse then using int 56-bit accumulation.
depends on how loud the signal is.
> However SHARC native is 40-bit floating point which gives you extra 8 > bits, which could be barely sufficient for what you are trying to do.
with those 8 extra bits, you should be able to, on average, accumulate 256 terms in the 40 bit accumulator and have, on average, before a noticeable bit error in the 32-bit float that you're rounding to,
> SHARC supports for 32 bit integer MACs with 80 bit accumulation. This is > the way to go.
Al Clark might agree with you. r b-j
"robert bristow-johnson" <rbj@audioimagination.com> wrote in 
news:1135023945.749309.153870@o13g2000cwo.googlegroups.com:

> > Vladimir Vassilevsky wrote: > >> >> The IEEE-754 4-byte float has only 25 bits of precision, so it is not >> going to help any. > > it will an improvement over fixed point for low-level signals. > >> Indeed if you do MACs in float, it is going to be >> much worse then using int 56-bit accumulation. > > depends on how loud the signal is. > >> However SHARC native is 40-bit floating point which gives you extra 8 >> bits, which could be barely sufficient for what you are trying to do. > > with those 8 extra bits, you should be able to, on average, accumulate > 256 terms in the 40 bit accumulator and have, on average, before a > noticeable bit error in the 32-bit float that you're rounding to, > >> SHARC supports for 32 bit integer MACs with 80 bit accumulation. This
is
>> the way to go. > > Al Clark might agree with you.
I do. Al
> > r b-j > >
-- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com