Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments

PrevNext  Index
DateMon, 18 May 2009 22:50:01 +0100
From Krzysztof Foltman <[hidden] at foltman dot com>
ToFons Adriaensen <[hidden] at kokkinizita dot net>
CcNedko Arnaudov <[hidden] at arnaudov dot name>, Linux Audio Developers <[hidden] at lists dot linuxaudio dot org>, JACK Developers <[hidden] at jackaudio dot org>
In-Reply-ToFons Adriaensen Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Follow-UpFons Adriaensen Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen wrote:
> 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
PrevNext  Index

1242683435.18073_0.ltw:2,a <4A11D809.2080408 at foltman dot com>