> > > 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. Stephane _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
