Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Nov 21 2000 - 00:26:59 EET
Lots to write in reply to this one, but I am dog-tired, irritable,
dehydrated, etc. so just a short comment:
>> Signal1<void,Audio *> input_ready;
>> input_ready.connect (slot (plugin, &Plugin::run));
>>
>> results in:
>>
>> plugin->run (Audio *data);
>>
>> being called every time we do "input_ready()".
>
>Right. Now I see why you were referring to libsigc++. You can do this,
>certainly, and use sigc++ as replacement for a function pointer.
>
>Basically, what we are talking about is two concepts:
>
> * the plugins implicitely schedule themselves, since they are emitting
> signals, which will lead to other plugins being called, which emit
> signals, ... and so on ... until in the end effect, the flow graph
> calculates itself periodically
>
> * the plugins are scheduled, i.e. a scheduler finds out which plugins
> should be called when, with which blocks of data, to achieve the
> execution of the signal flow graph
my example wasn't clear enough. the "input_ready" signal is emitted by
the "scheduler", not by a plugin. the idea is simply that the emitter
(and/or owner) of the signal has *zero* knowledge of who is connected
to it, and the recipients of the signal know nothing about the emitter
(though in many cases thats not necessarily true; it just *can* be).
ignoring libsigc++ for the time being (because its not part of LADSPA
at all): the scheduling in my proposed system is actually extremely
simple:
ALSA poll(2) support:
* wakes up a thread very fragment
* this thread handles the low-level interaction with the audio h/w
and calls the "run" method for the patchbay/router/host.
The patchbay/router/router simply executes the "run" method
for every plugin connected to every input port, then
executes the "run" method for every plugin connected to
every output port.
Note: there can be no complex networks at this level, and so
there is no need for any handling of feedback/delay loops
etc. these might exist in some of the plugins that are
executed, but thats their business, not the router's.
Then it returns control to the audio-h/w function that was
calling poll(2), which does any closing stuff needed, and
then returns to poll(2) again.
there's nothing more here than a poll(2) loop and a series of (likely
nested) "run()" calls on a series of plugins.
well, there is the connection of plugins to the ports on the
router. thats handled by a series of lock-free-FIFO request
queues. the router grabs requests for (dis)connections (if any) when
it is "run()" by the audio-h/w-poll(2) loop.
--p
This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 01:20:57 EET