[LAD] [Jack-Devel] A picture...of the global mess
nando at ccrma.Stanford.EDU
Mon May 25 23:26:27 UTC 2009
On Tue, 2009-05-19 at 21:39 +0200, Fons Adriaensen wrote:
> 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
I would agree (sorry for the late response). Dbus _is_ actually a
server, and an external one that does not have anything to do with jack.
It is just convenient, but the assumption that it will always be there
> 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
> 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.
More information about the Linux-audio-dev