Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 04:04:16 EEST
On Sat, 25 Mar 2000, Karl W. MacMillan wrote:
> On Sat, 25 Mar 2000, David Olofson wrote:
>
> > Yes, obviously you have to get the job done.
> >
> > But are you going to use another API for price sensitive production
> > systems...? This contradicts the whole idea of a standard API, and
> > leaves us where we are now - nothing but dedicated, specialized APIs
> > that are about as reusable as Microsoft APIs.
>
> What contradicts the whole idea of a standard API? All I am talking about
> is that 32 bit floats may not always be the best choice for a given
> architecture or situation. I'm not even talking about the API! If
> anything I'm arguing for allowing the programmer/user to choose the
> performance/quality they want/need in a very broad sense.
Ok, sorry. :-) I must have gotten the impression that the point was
that *only* 64 bit data should be supported - which is just a waste of
bandvidth for most systems.
> > > 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?
> >
> > Does that mean that there won't be development after the 1.0? If not,
> > versioning will force everyone to upgrade, or at least recompile
> > everything every few months, or alternatively, ignore any new plugins
> > or applications.
>
> Huh?
Looks like I forgot what I was actually commenting on. Amazing... :-(
Anyway, specifying the (single) data format in the header breaks
binary compatibility if that format can be changed. Of course, hosts
*can* be written to handle multiple plugin versions at run time...
> > > 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.
> >
> > This won't work in real life unless all development is centralized.
> > The whole point with plugins is to make things pluggable; not to save
> > some RAM through dynamic loading of "built-in" code modules. How many
> > versions will there be? Why should people upgrade their code to the
> > latest version when it doesn't add any features they need? Can a
> > host support all versions without expensive or complicated hacks?
> >
>
> Why does development need to be centralized? I am making two assumptions:
> 1) the api will need to change at some point (hopefully not anytime soon,
> but eventually it will) 2) the host and plugins need make certain they are
> speaking the same language (ie they use the same API). I was trying to
> suggest that there be some means of verifying API version (again,
> hopefully it will never be anything but 1.0 but allowing for the future is
> what started this whole debate).
Of course, versioning is essential, even if we're hoping that there
won't be any binary incompatibilities. Better safe than sorry.
> At the same it would be possible to
> check for the float size the plugin was compiled with (v1.1-64 meant v1.1
> + size of LADSPA_Data). I am imagining downloading a host and running
> ./configure --with-64bit-plugins=true and then compiling your host and
> pplugins for 64bits. All this could probably be done with a few #ifdefs
> and macros. So we are talking about, hopefully, one version.
Yes, but there mustn't be a need to recompile unless we're enforcing
the GPL as a requirement for using the API. It would be nice if all
plugins case as source, or compiled for the major data types, but I'm
not expecting that to happen...
> As to your
> last two questions, again I am not sure what you are getting at.
The first one is related to my confusing versioning with multiple
data types. The point, if any, was that this is what happens if
everyone decides on a de-facto standard format, and that format is
changed later on, to reflect the increased CPU power and demands on
quality.
As for the second one, this is what you get if you can't or don't
want to use the same data type for all plugins in your setup.
> > Important point: Who decides what format to use?
> >
> > (Hint: The user and the developer may not always be the same person.)
> >
> > Also note that we don't have a $,$$$,$$$ machine to push developers
> > and users around to use whatever standard we decide on. They will use
> > the official standard, or fork/break the API.
>
> How am I pushing people around? Why do you think this email address is an
> alias for Bill Gates? How do any of my suggestions change who gets to
> decide which format to use?
I was to some extent confusing your suggestions with my own idea of
what compile time data types mean for plugin binaries and hosts. As
there are ways for hosts to support more than one format, the above
is irrelevant.
Also, I hope I'm not giving the impression of being as rude as to
point someone out as the one behind That Other OS! ;-)
> > > Allowing multiple data types will make both the API and the
> > > plugins MUCH more complicated with little gain.
> >
> > No. I noticed Benno has been working on one solution, and I have
> > another one (don't know how similar they are). My solution means no
> > more work than for plugins to provide a list of data type descriptors
> > for it's ports, and for hosts to make sure not to connect ports with
> > different data type descriptors. Here's a snippet from my
> > work-in-progress:
>
> <snipped API suggestion>
>
> How is requiring the plug-in writer to simultaneously support seven data
> formats not more work for the developer?
This is not a requirement, or even a suggestion.
Actually, you may ignore all formats but the one you want to support,
and thereby force the host (or user, for a lazy host) to insert
converter plugins where needed. You *may* support all formats, and
even use custom formats (*) without the host needing to understand
it.
(*) You really shouldn't invent new data types without getting their
IDs into the official list, as that may eventually end up in users
wondering why they get bad crashes when they connect certain plugins
that *seem* to have compatible ports.
> > > 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).
> >
> > Using plugins for different primary target environments, or just
> > coded by developers with different ideas. Allowing a set of plugins
> > to communicate something that the average host won't understand.
> > Using plugins for processing all kinds of signals and data, rather
> > than high end audio only.
>
> What type of data can you not transfer between plugins as vector or scalar
> floats that the data types that you added will allow?
In theory you cold probably pass anything that way, but if you're
going to use MMX, deal with high frequency data (like from digital
oscilloscope cards) or video data, it's not very suitable.
One could argue that this API will only be used for "power consumer"
through high end audio, and that plugins using different data types
will never run under the same host, bit I think that's too
restrictive.
> > Is it really a good idea to cripple the API just to remove a few
> > instructions from the simplest hosts? Any host that wants to support
> > more than one data format will be a lot more complex and messy than
> > *any* host for an API that supports multiple formats from the ground
> > up.
> >
> > If you *really* don't want to support more than one format in you
> > host, you can just scan * PortDataTypeDescriptors, and refuse to use
> > plugins with anything but your favourite data format, rather than
> > checking before making connections.
>
> You have it backwards - I want to make it easier to write plugins not to
> write hosts. It is a choice between making every plugin potentially do
> lots of conversions and handle lots of data types (and there will
> hopefully be thousands of plugins) or making a few (or at least a lot less
> than plugins) hosts support data conversions.
* A plugin will not be forced to do anything but declaring what
format is used for each one of it's ports.
* A plugin may be compiled in different versions with different
formats, if the developer is nice enough to follow the
recommendation of providing plugins for the major data types.
* Host do not have to support *any* data types. They can get
away with uning only the element size field of the data type
descriptors, and use interface/driver plugins to communicate
with the outside world.
* Hosts are required not to allow direct connection of ports
of different types.
* Hosts may use an array of plugins, or inline code to convert
between formats as needed. This can also be done manually by
the user for the simplest hosts.
That is, plugins are basically coded the same way as if the data
type were fixed at compile time, but instead of putting the data
type ID in the version code, there's one field for each port. Data
typing is still static after compile time, but you may have ports of
different types on the same plugin.
The host gets to do the work, actually. It has to compare the data
type IDs before connecting ports, and take some action if they're
different. It also has to understand the data types it wants to
operate on directly, unless it leaves that to special purpose
plugins. At can get away with understanding only one type, and using
converter plugins, just like when connecting incompatible ports.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 05:45:52 EEST