Subject: RE: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: la maalis 04 2000 - 13:09:01 EST
On Thu, 02 Mar 2000, Kai Vehmanen wrote:
> I'm especially interested in control data routing. David said earlier
> (correct if I'm wrong), that the transfering engine/host doesn't need
> to know about the data that is passing through.
I was actually thinking about the audio/video/<whatever> data, but
this applies to control data as well. There is a difference between
my current MuCoS design and LADSPA here, as MuCoS passes control data
directly inside the events, which means some of the data type
abstraction goes away WRT controls. It can be solved by simply
allowing events to carry elements of the same data types used for the
frames of the signal ("audio/video/<whatever>") data, but I'm still a
bit unsure if this is really a good idea...
> However, someone still
> has to know how to create the data, and thus the creating object has
> to know about the target object.
The "creating object" will be a plugin; a real one, or one that's
hardcoded into the host. From the logical design perspective, it
should *never* be a part of the host - there's no point in handling
that in the API spec, as far as I can see.
> And when the engine needs to connect
> these objects, it has to know whether their parameter-types are
> compatible.
Yes. There will have to be data type codes that identify data
formats.
The event type codes must be managed centrally, so we don't end up
with people using the same codes for different data types. Nasty
things will happen if you mix plugins with a conflict of this kind...
To eliminate most crashes due to conflicts (when someone just grabs a
code to get on with the prototyping of a new format) there should be
some form of data type descriptors that contain info on size of an
element, kind of data (float, integer, fixpoint,...), some author
name etc. (The size field will be required by MuCoS, is these data
types are to be used inside events.)
> In the end, all parts of the system have to
> be aware of the various data types used.
No, only the parts that operate on the data. Plugin hosts and the
inter-application communication API won't, unless they have their
own built-in plugins for performance reasons.
> On the other hand, by using
> very generic types (ie. floats), you avoid most dependency problems
> and you get better performance.
This is too restrictive IMO...
Multiple formats can be handled by providing a set of translation
plugins, to be used when people want to mix plugins that use
different data types. This should be avoided for performance reasons,
but I think it's plain wrong to have the API enforce hardcoding of
the data format into all plugin hosts. That would fragment the
plugins into different classes, using different formats, with few or
no ways of integration. Having the ability to run a 16 bit int
plugins together with 32 bit float plugins would eliminate the need
for special, incompatible versions of the API.
//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 : pe maalis 10 2000 - 07:23:28 EST