On Sun, 2009-05-17 at 14:17 +0200, Fons Adriaensen wrote:
What I see as the most important thing, is that a client starting jack
doesn't need to know how jack is supposed to be ran. This is why
~/.jackrc was made, but this causes several issues for me. The most
important one of them being that the jackd server process is then
connected directly to the client starting it. If that client quits,
jackd dies (or leaves the client process hanging around until jackd is
no longer needed).
I hope to see from jack d-bus that clients will be able to tell the
environment (through dbus) that "I want jack". The environment has a
utility which is responsible for starting jack. This might be totally
invisible to the user (which fits a lot of people), or it might be a
more comprehensive tool like qjackctl. A tool that handles multiple jack
configurations. I run jack frequently with 3 different sound cards with
different parameters plus the dummy driver to do debugging.
As for execv(char *path, char *argv). What Marc meant was that there
could be (will be? is already) an API to give the client contorl over
server parameters without teaching every app what command line
parameters jackd has and how they're used.
Linux-audio-dev mailing list