Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Wed Mar 22 2000 - 02:35:31 EET
Ok - I'm confused. After reading David's email about normilization to 0db
and this one I realized I was making the assumption that the audio data
would be normalized to [-1,1]. Switching between 32/64bit floats is
simply a change of data type in this scenario - and could be accomplished
by changing a #define and recompiling all of your plugins (or if the
plugins don't with source two versions would be easy to produce by the
author). Actually, as long as 0db is specified as a power of two (like
David was saying) does it matter if the floats are 32/64/128/etc? What am
I missing?
Karl
On Tue, 21 Mar 2000, Benno Senoner wrote:
> Hi,
>
> I am just reading in Keyboards magazines that more and more 24bit soft-synths
> for Cubase/Logic are becoming available , or are being developed.
>
> Therefore I ask the question again:
>
> did we agree about 64bit FP ( the "double" datatype ) support in LADSPA ?
>
> I say this because , although 32bit floats provide 24bit mantissa,
> having a few sound sources (plugins) which deliver true 24bit quality,
> will cause precision loss while the 24bit data travels the signal-path
> from one plugin to another.
>
> ADAT I/Os or 24bit ADCs/DACs push the float type to the limit.
>
> If you studied Calculus, you know how fast the precision can vanish,
> when you have to deal with algorithms which show up some numerical
> instability.
>
> Therefore for full 24bit audio quality the 32bit float is simply not enough.
>
> Therefore I think LADSPA plugins should have a flag to tell the host
> if they support 64bit processing.
>
> the plug should set which modes it supports:
>
> LADSPA_PROPERTY_SUPPORT_32
> and
> LADSPA_PROPERTY_SUPPORT_64
>
>
> all 3 combinations ( 32bit only, 32bit and 64bit , and
> 64bit only) should be allowed,
> where 64bit-only is STRONGLY DISCOURAGED, and would
> not run on "simple" hosts, these which do not support data
> conversion.
>
> Simple hosts (32bit only) will simply refuse to run 64bit-plugins
> (or if they support 32bit the host will use the 32bit version)
>
> Complex hosts can do optimize things ,and in the case that every member
> of a plugin-chain (and the user wants 64bit mode), it can run the plugs
> in 64bit mode.
> Or alternatively if there are 64bit-only plugins (will be rare, not
> recommended) among 32bit-only plugs in a chain,
> the host will do float <--> double conversion.
>
>
> I know, the response will be this makes the API more complex,
> but that is not a big deal IMHO,
> because you can simply provide 2 callbacks:
>
> run() and run64() or something,
> or if you want only run() and let the host instruct the plugin which mode it
> wants during instantiation.
> (the plugin will the set the run() function-pointer to the appropriate value
> ( internal run32() or run64() )
>
> I don't think that 64bit FP support belongs to MuCoS (I see MuCos as the event
> system), since it will make 32bit to 64bit transition much more complex.
>
> just use void * as datatype for input/output samples in the plugin API, and
> let the host agree about the use of 32bit (default, highly recommended) or
> 64bit. (in this case the plug should provide a 32bit version too, in order to
> make it easier to be runnable on simple hosts)
>
>
> The "bloat" of the API by adding 64bit support is really tiny compared
> to the benefits.
> It will save us a lot of trouble in the future.
>
> DVD audio, and other emerging digital audio media , will make the float
> datatype obsolete when it comes to high quality audio processing.
>
> I think if we don't add 64bit support now, we will regret it sooner or later.
> And having to deal with a different API when dealing with 64bit makes me
> unhappy, because it will lead to lots of incompatibilities and troubles.
>
> any thoughts ?
>
> Benno.
>
>
>
_____________________________________________________
| Karl W. MacMillan |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services |
| karlmac_AT_peabody.jhu.edu |
| 410/659-8297 |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Wed Mar 22 2000 - 03:05:50 EET