Re: [linux-audio-dev] LADSPA 64bit FP support ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Mar 22 2000 - 20:28:45 EET


On Wed, 22 Mar 2000, Paul Barton-Davis wrote:
 
> >going to hear it. You have to be in a very quiet place to hear even -60 dB.
> >The only reason those bits need to be there for integer signals is to
> >represent the quiet signals. FP doesn't have a loss of quality problem for
> >quiet signals.
>
> Who can hear sample accurate response to MIDI controller data ?
>
> Just as SC puts a premium on real-time, sample accurate performance, I
> think that software that does HDR should be able to do what dedicated
> digital recorders do. If you were about to buy or download a software
> HDR system, and then heard that unlike an ADAT or DAT recorder, it
> dropped bits (albeit from the low end), what do you think you would
> do? More importantly, what do you think most professional studio
> owners will do?
>
> All that said, I suspect that the benefits of converting to 32-bit FP
> probably outweighs the disadvantages, for precisely the reason you
> provide. Being able to run a bunch of really hot channels into the
> same bus, and never worry about clipping is a nice feature, even if
> the int32<->float32 performance of the x86 sucks bigtime. Its just a
> question of how to deal with the question about bits-in vs. bits-out
> in a way that won't scare away people used to "perfect" recording from
> digital devices.
>
> --p

Pau I fully agree,

let's take a very simple example how a normal floating point addition can
generate a relative error of 60%

let's assume we work with 5 significant mantissa digits:

x = 103.524 (precise value)
y = 103.530 (precise value)

x-y = - 0.006 (precise value)

float(x) = 103.52 (rounded down)
float(y) = 103.53 ( rounded up)

floating point subtraction:

float( float(x) - float(y) )= float ( 103.52 - 103.53) = - 0.01

now let's calculate the relative error:

( 0.006 - 0.01) / (0.006 ) = 0.666 = 66% error !!

even if every plugin uses 64bit fp internally, the data transfer between
plugins using only 32bits, could cause the loss of a FEW bits, not only one.

Therefore 64bit FP gives us much more bit-saefty.

Since we are designing for current and future high-end audio on Linux,
64bit support is needed.

Or we will run soon into an "Y2K for audio" problem.

trying to deliver in-bits == out-bits at 24bit quality using only floats
is just hopeless.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Mar 23 2000 - 12:18:58 EET