5 Feb
2008
5 Feb
'08
10:39 a.m.
On Tue, 2008-02-05 at 15:34 +0100, Stéphane Letz wrote:
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
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.