Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka 09 1999 - 18:24:20 EDT
On Sat, 09 Oct 1999, Kai Vehmanen wrote:
> Ok, we have a event system where something creates events,
> events are sent to plugin-instances, plugins parse the
> events (?) and act accordingly, someone triggers plugin
> processing (by sending the actual data).
>
> Then to the question... when I load a plugin, how/where do I get info
> on what kind of events this plugin accepts, how many parameters it
> accepts and what they control, what are valid values, etc.?
Next level: "What is the event system used for?"
A while back, I got the idea of adding an init() callback function to
the plug-in. The intention was that it should eliminate the need for
a structure with hardcoded info entries, or a set of callbacks. As
the same API could be used for that, and for the real time event
system, there would be nothing more than a few event IDs to keep
track of.
As a result, binary compatibility accross versions is made easy, and
plug-ins don't need a single line of code for features they don't
care about. (Hold it, C++ freaks! What does the compiler actually
make out of inherited members that you don't override?) The same
init protocol also maps nicely to the client/server API, which
further reduces the difference between plug-ins and clients. Less
boring API stuff for hackers to learn, and more flexibility for users.
I still think this is the way to go, but all details aren't worked
out yet... When the rest of the plug-in API stabilises a bit, I'll
hack some plug-in instantiation and client/server init code to see
what it actualy looks like.
The big job here is to define the events to use for this, and specify
strict rules for their use, ie which ones do you *have* to specify;
do they have to be sent in a specific order; what are the defaults;
how to resolve engine/plug-in/client/server requirement conflicts and
so on...
Something to start with:
1) Init events can be sent in any order (from the client/plug-in),
and will be treated according to well defined dependency rules.
(As opposed to OSS ioctls(), where order *does* matter, and
weird things can happen if you break the rules.)
2) An init (or re-init, when someone wants to change something)
sequence can involve groups of events that may have
dependencies, and should therefore be handled as a homogenous
transaction.
For plug-ins, this is automatically guaranteed, as each group
of events is constructed during a callback from the host.
For clients that communicate through shared memory, it gets
more complicated. Unless the actual transfer of queued events
is controlled through a "commit" action from the client, it's
possible that the server gets an incomplete set of init
events. I propose a "commit" method for event ports, as this
can simplify other things as well. (This does not apply to
plug-ins, as they issue an implicit "commit" operation when
the process() callback returns.)
3) Buffer size requirements and similar things should be handled
through request/reply sequences. (The host/server requests a
certain value, and the plug-in/client replies with the
closest value it supports.) This is probably one of the most
complex parts to get right...
4) Parameters (applies to clients, engines and servers, as well
as plug-ins!) should use standard control event classes
(which implies that the range, unit and behaviour adheres to
the standard) as far as possible.
5) The actual representation of parameter values is determined
by the control event class (4), but some tunable properties
allow better control of the visual appearance and control
behaviour, when the parameter isn't controlled by a custom
UI element.
6) Parameters that do not fit in a standard class will have to
go into a custom class. The properties of these events must
be defined during the init sequence. Custom events should be
*avoided* as far as possible, as they effectively eliminate
the usefullnes of the event system. (How do you automate
a parameter that you don't understand?)
IMO, this is where the API gets *audio* specific. Similar sets of
init events can be defined for video and other formats, without
affecting binary compatibility. That is, an engine could host both
audio and video plug-ins without understanding the data formats
involved. The only requirement is that it can handle the low level
routing of data and events, and that it supports the client/server
API, so that the plug-ins can be connected to some data sources and
device driver interfaces. (Of course, such an engine wouldn't allow
much optimization, which is why the client/server API is important.
Use one dedicated engine for each format - your favourite automation
application will still be able to control everything.)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST