Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

"robert bristow-johnson" <r...@audioimagination.com> wrote in 
news:1...@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

______________________________
DSPRelated.com's 50,000th member announced! Details Here.