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? Otherwise, starting a single client will prevent any control application started later from being able to do its job. In non-DBUS JACK the application that started jackd had a monopoly on access to its stdout/stderr. Also, what if the application that did fork and exec crashes? What if the server crashes? What if both crash, but other control applications are still running? 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). Krzysztof _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
