linuxaudio.org

Fons Adriaensen wrote:

quoted text
> There is IMHO *no* reason why jack-dbus should

> **intercept** C API calls, start its daemon,

> and take control.

Hmm?

libjack from non-DBUS package detects if JACK server is running, if not,

it starts the server by doing fork&exec.
libjack from DBUS package detects if JACK server is running, if not, it

starts the server by telling DBUS server to do fork&exec.
I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or

eating babies.
It may be harder to notice that the libjack-using application has just

started the JACK server because the server's output goes to a log file

and not stdout, but some people actually like it that way (especially

when used with tools like laditray).
I'm not saying DBUS version should be used by everyone, or that the

currently available set of tools can be safely used by general public.

On the other hand, I'm not buying into any anti-DBUS hysteria, because

the "JACK server as a background service and not stdout-spamming

application forked out from random client process" makes a lot of sense

to me.
Krzysztof
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev