Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: David Olofson (david_AT_gardena.net)
Date: Sat Apr 01 2000 - 23:38:04 EEST
On Fri, 31 Mar 2000, Paul Barton-Davis wrote:
[...]
> Connecting them together: now, how does a standard, daemon-style host
> connect them together ? You'd have to have a (G)UI that allowed the user
> to specify the routing, then relay this information to the
> daemon. What you're describing now sounds more like a replacement for
> esd.
>
> Hmmm. You know, after a moments thought, I'm not so sure that this is
> such a terrible idea. 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. The Daemon GUI app could also, of course, provide
> plugins of its own to insert into the flow graph.
>
> One can easily imagine how this would be used to create a generic
> Linux user-space sound daemon, with a lot of potential. It would have
> no coupling to X Windows, so it would work in console mode too. It
> could do anything that a plugin existed for. It would have low
> latency, because the plugins all run in the same address space.
That was the original idea of how Audiality would work. (Although
Audiality was primarily meant to run under RTLinux.)
> 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.
This is where the plugin<->client/server transparency of the MuCoS
event system comes in. If events (*all* events, including stream
buffers and out-of-band [w/o timestamps] events) can be passed
between clients, clients/hosts can easily support connections between
plugins running in other clients/hosts. No special API required. If
one client or plugin vanishes for whatever reason, that is handled as
if a plugin was removed from a host. Output ports are routed to
"/dev/null" and inputs get no more events, or (for streams of the
kind used for audio) get connected to a fake zeroed buffer in the
local host. If a plugin ends up not being connected at all, it may be
suspended or removed.
Now, if GUIs are plugins or clients, this is no different from any
other plugin<->plugin connections. Cool, eh? :-) (Ok, we still have
this nasty toolkit mess that more or less prevents hosts from running
GUI plugins using different toolkits, but at least, the ones using
the same toolkit can run together if desired.)
BTW, obviously, the client/server style API needs to be safe and
handle application crashes. I'm not sure if it can be done with just
shared memory and libs, but it's not completely unlikely. There is
always the kernel daemon way, but it would be nicer if the
client/server communication layer is at least *possible* to implement
in user space, even if it can't deliver the same performance and
stability that way.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Apr 02 2000 - 02:17:13 EEST