Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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
          


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 01:20:57 EET