Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka 10 1999 - 01:42:51 EDT
On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> >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.
>
> actually, i had always assumed there would be an init() function to
> get things set up. but from your later talk about init stuff, its not
> clear what you think this function should do.
>
> my model of "init()" would be something that does basic data
> initialization on the plugin's own internal data structures. it
> doesn't involve the event system at all.
>
> what do you have in mind ?
It should do both. The event system is used instead of the
structures or callbacks that many other plug-in APIs use.
> You didn't talk about a way to query the engine to see what
> event_ports can be subscribed to by a plugin. e.g. "is there a MIDI
> input port?"
#ifdef UNOFFICIAL
#define MCS "Multimedia Communication System"
#endif
That should be a part of the MCS, I think... That is, I want a
distinction here, as you should be able to run a system with no
engine at all. The MCS should provide a client/server API, *and* a
way for clients and servers to find each other in the system.
An engine that wants to make plug-ins accessible for external
automation, or a kernel driver package that wants to provide some
services, should act as a gateway, allowing their local plug-ins to
act as clients in the system.
I think that building the necessary protocols on top of the event
system will make this more flexible and useful, as it has an inherent
recursive nature.
> >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...
>
> i don't think we should support this. plugins *must* handle any size
> buffer. the buffer size should be controllable by the engine, either
> once at startup, or during runtime if there is a good reason to do so.
>
> why would allow them to do otherwise ?
DSP code optimization. If the algorithm really *needs* a certain
buffer size granularity, and the engine don't give a damn, the plug-in
can only handle it by doing it's own internal buffering, which means
copying. The engine can just adjust the buffer size to the best
alternative that fist all plug-ins in the sub net, or put the plug-in
in a sub net of it's own. That means that the buffer size adaption
can be done without copying overhead, and without extra code and
buffers in the plug-in.
> >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?)
>
> i have a feeling that you are thinking of things a little backwards to
> the way i am. my model is that the events that get sent to a plugin
> don't say "change parameter N to X". They say "something changed to
> Y". Its up to the plugin to decide what that means.
The only difference is that my plug-ins actually tell you during
init what events they care about. We could actually do it like VST;
force every parameter to be a float between 0.0 and 1.0, and support
nothing else. That eliminates the need for control event classes.
> automation - ah, automation. the first level is not that hard: we just
> record the events in some file, and then play them back. this will
> work fine for controlling the plugins. the GUI, which will
> need to be controlled since we want the on-screen representation to
> show us what the automation system is doing, is a lot more
> work. whereas the plugins will get exactly the same kinds of messages
> they always do, the GUI will be getting a set of messages that it
> normally doesn't get at all. normally, it just reads stuff from (for
> the sake of argument) the X server connection. but now, it has a whole
> new event stream to deal with, and it has to map them back to its own
> world of widgets, etc.
>
> still, it can be done, its just harder.
No way around that, not without getting 99% GUI dependent, I'm
afraid...
> so, plugins don't need to publish parameters, or their
> characteristics. they just subscribe to available ports, which the
> engine must make available.
I don't like that since I don't think connection management belongs
in the plug-in code, and I do think that it's a good idea to be able
to tell what a plug-in actually cares about. And the characteristics
*have* to be published one way or another, or you're forced to use
the plug-in's custom GUI for the values to make any sense.
> another optimization just occured to me. to prevent the engine from
> having to traverse the entire list of subscribable ports during each
> control cycle, there should be a way (preferably lock free, although i
> doubt that it can be done) to push a port that is in the "available
> for subscription list" into a "has events pending list". that way, for
> the vast majority of control cycles, the list to traverse will be
> empty! big win.
It's possible. Push the address (or some handle) of the ports that
you write onto a single queue. Then the engine just looks there to
see what's happened since last time around. You still need to check
one queue per thread/thread connection, as the queues are single
writer. Still a lot better than checking every single event port
every time, though.
//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