[LAD] New proposal for the jackd/jackdbus mess

Stéphane Letz letz at grame.fr
Wed May 20 12:06:17 UTC 2009

Le 20 mai 09 à 13:55, Krzysztof Foltman a écrit :

> Stéphane Letz wrote:
>> Not really, the existing IPC server/client scheme just need to be
>> extended with new "calls".
> Okay.
> Then, if you're keeping the "fork and exec" method of starting the
> server, will it in any way be guaranteed than all control clients will
> have the same functionality as the client which initially started  
> jackd?

Why not?
> Otherwise, starting a single client will prevent any control  
> application
> started later from being able to do its job.

In what way?

> In non-DBUS JACK the
> application that started jackd had a monopoly on access to its
> stdout/stderr.

Not clear for me.

> Also, what if the application that did fork and exec crashes?

Same behaviour as now, the server detects crashed client and stops if  
started in "temporary" (-T mode)
or continue to run if started non temporary.

> What if
> the server crashes?

As usual, client can detect that using the "shutdown" callback.

> What if both crash, but other control applications
> are still running?

  "shutdown" callback.

> I think that in any correct solution, the fact that
> an application has started jackd shouldn't give it any more (or less)
> influence on jackd than any other client in the system - otherwise  
> it is
> a race condition. The hypothetical new version of qjackctl should have
> the same feature set no matter if it was started before or after, say,
> Hydrogen.
> Can the same IPC protocol you plan to use for the control protocol be
> reused for the out-of-band MIDI SysEx data? (we've been talking about
> that before, and it's really out of scope of control protocol
> discussion, but it might be useful at some point).

No idea right now. I think we should focus on the global design.


More information about the Linux-audio-dev mailing list