Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: David Olofson (david_AT_gardena.net)
Date: Wed Mar 22 2000 - 03:13:09 EET
On Wed, 22 Mar 2000, you wrote:
> 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?
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.
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!
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.)
The distinction is important in that is isolates the whole data type
issue as something to be sorted out at plugin implementation time,
rather than as a part of the API. (Of course, the data type codes and
formats have to be standardized extensions of the API spec, or it'll
be quite complicated to find two plugins that can be connected
directly.)
What this means to the API is
1) Signal and control port data pointers are void *
and either
2a) Every port gets a data type field
or
2b) Every *plugin* gets a data type field
2a) makes more sense to me, as the data type field would be a
property of the port rather than the plugin, and since it allows
plugins to have ports with different data types. The latter brings an
important thing as a bonus; the ability to do data type conversion
using ordinary plugins - inlined or dynamically loaded.
As for hosts, there are a few levels of support for this that can be
implemented;
1) "We don't like multiple datatypes!"
The host simply treats plugins according to the current
LADSPA spec, with the exception that it will just refuse
to load plugins with unsupported data formats.
2) "Ok, but we don't want to see much of it."
When the host loads plugins, it "packages" them together
with appropriate converter plugins, so that it'll get
entities with ports with only one data format - the
engine's native data format.
3) "Fine, but it's up to the user to get it right."
The host makes no assumptions about the data format
used for the average plugin-plugin connection - the only
thing it does is to make sure that ports with different
formats cannot be connected. As for touching data
directly ("internal ports" or inline optimizations), the
host does so only with data formats it understands. The
user has to plugin converters to connect any unsupported
formats directly to the host.
4) "Fully and transparently supported."
Like 3), but the host automatically tries to find a
suitable converter plugin when the user wants it to
connect two ports carrying different data formats. Of
course, this applies when connecting to internal host
ports as well.
(By "internal ports" I mean things like what some hosts use to
interface the engine to files, sound drivers etc. Normally, hosts
should use I/O plugins for that, but that doesn't work for all kinds
of applications.)
Solution 2 is the simplest one that still guarantees compatibility
with plugins using any data format, and it's a viable option for most
applications, as long as the majority of developers turn out to use
the same data format. OTOH, it's not very different from 3) in real
life, and it eleminates the need for convert+convert back when
connecting two ports carrying a non-native format... Well, that's for
the host developer to decide!
Ok... I hope I'm not making this look more complicated than it is.
It's basically about allowing hosts and plugins to use other data
formats without breaking the API, rather than forcing anyone to
support anything. If we should support two formats, we might as well
support an "unlimited" number of formats, as it ends up resulting in
about the same complexity.
//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 : Wed Mar 22 2000 - 04:41:18 EET