Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Wed Mar 22 2000 - 05:24:04 EET
>
> Even if computers get fast enough to handle 64 bits all the way
> through, 32 bits will still be faster and good enough for many
> applications. No matter how fast the bus is - less data always get
> accross faster.
>
I'm not convinced that this is the case - 32 bits is always faster if the
bus is the limitation but what if you are cpu bound on a 64 bit processor?
Isn't the natural word size for any given processor always the fastest?
Regardless, choice of data type never has speed as the first choice at
this point. If you need 64 bits to get the results that you want you are
going to use 64 bits and buy a faster computer. Otherwise I would be
using 8 bits 22500 hz audio.
> The API problem is that this has to be done at run time, unless we
> want to end up with two actual standards used in parallel. This is
> not a transition thing, but two different data types with slightly
> different uses.
>
> There's no way we can make sure all plugins are available both in 32
> bit and 64 bit versions, and not specifying support for both in the
> API might end up as a big mess. For starters, how would a host
> identify the dataformat of a plugin unless it's specified in the API?
> If it's not possible to do in a safe way, and the user have both
> kinds of plugins - boom!
>
I was assuming that the host and plugins would be compiled against the
same header using the data type specified there. Is there no some type of
versioning built-in to the API now? It seems to me that the general
solution would be to check for a API version (v1.1-64 or v1.1-32) when
loading plugins to assure both binary compatibility AND data type
integrity.
>
> Anyway, I still believe the data formats should be separated from the
> basic API. Ports should handle blocks of any number of bytes, and on
> the binary level, at process time, the actual formats are determined
> by the plugin code and any inlined host "plugins" that deal with the
> data. Port compatibility is checked by the host when making
> connections, or when loading the plugins. (Notice the distinction: The
> latter implicitly states that it's not allowed to have plugins that
> can instantiate with different data types from the same class. This
> matters a whole lot to real time instantiation capable plugins and
> hosts.)
>
<snipped lots of stuff>
I guess I don't see any advantage to having different data types at
runtime passing between plugins. Yes, if you specify data types on a per
port basis you can create conversion plugins, but to convert what? 32 to
64 bit floats or vice versa? Either you want 64 bits - in which case
there is little point to using 32 bit floats in the plugin network - or 32
bits is good enough and you wouldn't want to use 64 bits because of the
overhead. Allowing multiple data types will make both the API and the
plugins MUCH more complicated with little gain. I can't see adding this
complexity just to be able to do conversions (and I can't think of any
other use for the multiple types).
Karl
_____________________________________________________
| 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 - 05:57:48 EET