On Tue, 2008-02-05 at 15:34 +0100, Stéphane Letz wrote: > > > > > > One way I'm investigating to more or less enforce this > > in an installation I'm designing is to have a second > > JACK instance that is not driven by a sound card but > > by a client of the 'master JACK' of which it becomes > > a subgraph. Then hide the 'master JACK' and all its > > clients. To the user it looks as if he's working with > > a normal installation, and talking to the sound card, > > while his 'system:' ports are in fact just another app. > > All it takes is a JACK backend that presents itself as > > a client to another JACK instance. Or a shared lib that > > allows any app to become a JACK backend. Or a version > > of JACK that has not one but several processing graphs > > and configurable links between them. > > > > That's one way to do it, another one is to use a 'flat' > > system (only one JACK) and rely on a session management > > system that supports hierarchical control. > > > This is interesting: "hierarchical" jack if I get the idea correctly. > I would be interested to understand better, if you take some more time > to explain your design in more details and requirements it would > establish to jack API.
AKA "netjack" :) it really almost exactly the same, except with two sockets as the interface between the JACK instances, rather than shared memory and IPC mechanisms. --p _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
