On Tue, May 19, 2009 at 04:49:07PM +0200, Stéphane Letz wrote:
> Note that we may remove the "jackcontrol + jackserver" separation by
> starting the server inside jackcontrol process. But then if the server
> crash, jackcontrlol is dead. This may be solved by an "jackcontrol deamon"
> automatic relaunch feature...
Having a permanent jackd - a real daemon started as a
service by the runlevel scripts - is the solution I'd
prefer.
You talk to it via libjack using the mechanisms already
present in jack - sockets and shared memory. It is this
jackd that will start a server, either requested explicitly
by a control client, or as the result of a jack client
using jack_client_open() to a nonexistant server. The
latter is detected by jackd via the normal libjack
paths.
Servers should probably be separate processes (so they
can be owned by a user).
For those that want it this jackd can have a dbus control
client, which could also be a daemon but this time started
probably from the login scripts.
What is gained is that there is ***no dbus inside jack***
It is this idea of using dbus for internal communication
that I find utterly revolting. It creates a dependency
on dbus (which is unnecessary) and on a session login
(which is limiting its use), and it opens the gates for
all sorts of sick desktop-zealot inspired persistence
and stability risks.
It's also just bad design, comparable to using a $3000
precision programmable voltage source in a circuit where
a 10 cent zener diode would do. Or replacing a fixed
cable by a switch matrix. Or talking to your wife via
a lawyer.
Ciao,
-- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Wed May 20 00:15:04 2009
This archive was generated by hypermail 2.1.8 : Wed May 20 2009 - 00:15:04 EEST