Krzysztof Foltman wrote:
So having
jackd behave in orthagonal way is not confusing? Like, jackd
process is running, why my apps cannot connect?!?!?
In normal situations, this
jackd process (the launcher) would be only
short-lived (less than a second).
Looks like I was wrong - you're assuming that starting jackd manually
would case that starter process to wait until it's manually stopped,
like jackd did before?
That might be a problem, indeed. Several solutions here:
1. Rename jackd process to jackd-launcher when it's determined to act as
a launcher.
2. Exit the launcher whenever the server is stopped via dbus. Stop the
jack engine whenever the launcher is stopped via kill (that might be
tricky because of kill -9). That's probably most complex, but gives most
backward-compatible behaviour (you can kill jack server the old way, you
can check for server exit the old way).
3. Assume a launcher is only a launcher and exists as soon as the JACK
engine is running.
4. Decide for implementation that doesn't use dbus and separate dbus
object process at all (ie. the launcher would double-act as jack engine,
only with dbus interface - is that possible to use dbus even when object
wasn't started by dbus?). This way, jackd would start the engine in the
same process, but the engine would be able to communicate via dbus.
5. Abandon backward compatibility altogether.
Sorry for confusion,
Krzysztof