Subject: Re: [linux-audio-dev] Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: to syys 23 1999 - 17:51:05 EDT
On Thu, 23 Sep 1999, Juhana Sadeharju wrote:
> >From: David Olofson <audiality_AT_swipnet.se>
> >
> >Hmm... I kind of like the hardcoding idea. But I doubt that it'll pay off:
> >Have a look at the engine side... And what if you have say 15 parameters of
> >which you may automate any few? That's a veeeeery long stack frame, most of
> >which will be unused most of the time. (Or am I missing the point?)
>
> Yep. But it is quite rare that all 15 channels are sent interleaved
> through one channel.
What I meant that it's more expensive for a plug-in to check for events on
multiple inputs than to check a single input and decode destinations when
events do arrive. The multiple channels will always be there, while you can
have huge event decoding case() statements without any extra overhead. (Ok,
you'll get cache problems at some level... ;-)
The problem is more obvious when the number of events per process() call is
close to, or less than the number of (connected) event destinations. This will
usually be the case in the kind of nets I have in minds... IMO, modular soft
synths should use control signals - not events - for the high bandwidth control
data.
> I see my plug-in suggestion needs an improvement in the cases we want
> send many channels to one plug-in. The function call would need to have
> variable number of arguments and thus the closure system seems to be
> much better. Besides I already moved to closure system.
Sending a pointer-to-pointer to buffer for inputs and one for the outputs (like
VST and my proposals do) is another way, but yes, closures are probably even
better, as you can just keep the array of pointers in there. No need to send
pointers on the stack, and no need for the engine to keep track of the
buffer pointer arrays separately.
However, how does the engine access the pointers in that case? I'd give the
plug-in the opportunity to decide where it wants the pointers, and then have
the engine ask for the addresses. About the same work as with my VST style
proposal on the engine side, but we get it nicely hardcoded on the plug-in
side. :-)
> >How do we access parameters (that are used less frequently) if they're not
> >"registered" as an event input in the current net?
>
> Parameters are part of the network. The network will have both the audio
> network and the control network mixed together.
Yes... As I want it - hard sync between event timing and timing of other data.
I was just wondering about the physical implementation, and where it fits into
your proposal with fixed destinations with individual input buffers.
> >(And BTW, if the code is supposed to be recompiled
>
> No recompilation is needed. The plug-in indeed has to test what kind of
> input/output systems (buffer, events, static) it should use.
>
> If you want avoid the test, then write specialized plug-ins: only
> buffer inputs and outputs are allowed (such as in Csound). It is up
> to plug-in author. I just wanted to provide more than one choise.
As long as it *can* be hard coded, it's very good indeed. But what happens on
the engine side? For example, two channels * three data formats = 6 different
plug-in call code blocks on the engine side to avoid any conditionals. (Unless
the engine can just threat all buffers the same way.)
[...]
> >Well, my idea was to make the basic system even simpler,
>
> Your system sounds more complicated than my system... yes it does. :-)
I wasn't thinking about the event system...! ;-)
I was thinking about the low level stuff used for telling the process() call
where the buffers are - which is basically reduced to getting a bunch of
pointers across. The plug-in is supposed to either keep track of what buffer
data formats the engine mentioned for each buffer, or it's simply hardcoded. In
the later case, it tells the engine "I want 32-bit mono data on all channels.
Period." in the init sequence, and then it just grabs the buffer pointers and
does it's thing.
[...]
> >I'm afraid that will result in two interfaces/subsystems that overlap too
> >much... And is your event system really that much simpler to implement?
>
> How would you implement the curve delivery in your system? Both static
> predefined curve and the real-time curve coming from other part of the flow
> network?
Many ways to do that. I suppose you're talking about curves with variable point
rates...? (Well, that's supposed to be harder to do, so... ;-)
First the easy part: Real time curves.
If you want it hardcoded in the plug-ins (which would be the fastest way), just
define an event type EV_DATA_CURVE, which can take any number of points.
(Dynamic event size - knew it would come in handy! :-) The plug-in just sees
the event, grabs the address of the data area (where the points are), and gets
on with it's work.
A simpler and more generic solution would be to simply have an event
EV_DATA_CURVE_POINT, that takes a point and a slope, or a duration and the
*next* point level. (Just to avoid forcing the plug-in to look up the next
event in the buffer to know where it should be going for the next few
samples...)
A slightly harder trick: Static curves.
Well, they could simply be send using the solution just described, but of
course, we don't like data copying. :-)
So, I'd just invent EV_DATAP_CURVE, which works something like EV_DATA_CURVE,
only it doesn't have the data points in the buffer. Instead, it carries a
pointer to the first point we should use in the static curve buffer.
(Obviosuly, the engine is responsible for making sure that the static data is
actually within the address range of the execution context of the plug-in code!
To keep in mind when trying to send this kind of events over network, or
between processes. That's why I want to encode it with a _class_ of DATAP, so
that an event gateway could convert all events of this kind into DATA class
events without having to know what the events actually carries.)
//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:12 EST