Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: Aaron Lav (asl2_AT_enteract.com)
Date: Fri Mar 31 2000 - 18:32:52 EEST
On Fri, Mar 31, 2000 at 07:35:09AM -0500, Paul Barton-Davis wrote:
> ... Imagine the scene:
>
>
> Daemon GUI app GUI for plugin A GUI for plugin B
> | | |
> | | |
> | | |
> Dameon(runs: plugin A plugin B plugin C(gui-free)
>
> The Daemon GUI app could be really trivial (I'm thinking of Maarten's
> cool little ALSA sequencer GUI that he did with FLTK recently), or
> something more like Cubase/Logic, but its fundamental role w.r.t. to
> the daemon is to tell the daemon to load/unload plugins, and how to
> connect them.
And, presumably, set and retrieve parameters for plugins (otherwise you
can't serialize/deserialize an entire setup from/to a file). (Parameters
can be blobs of uninterpreted data, so there's no loss of generality...)
> I see a potential problem with the relationship between the GUI's for
> plugins, which are distinct processes, and the plugins themselves,
> because this connection is subject to the GUI vanishing (X goes down,
> the plugin GUI app crashes) etc. Not good.
If the plugin could tell the daemon when it unexpectedly lost its
GUI connection, and the GUI's state was entirely retrievable from the
plugin, the Daemon GUI app could respawn the plugin GUI (with
rate-limiting like init(8), so a GUI which crashes on startup doesn't
cause too many problems). On restart, the GUI could just retrieve
its state (in the same way I imagine it would when first started).
Alternately, plugins could be responsible for launching their own
GUIs, but that seems less desirable: there's no central place to
monitor and control respawning. Either way, unless I'm missing
something, the problem seems soluble without too much hassle.
(Especially when you consider that the same sort of problem in a
multithreaded architecture would just shut down the entire process, no?)
Aaron (asl2_AT_pobox.com)
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 19:32:41 EEST