18 May
2009
18 May
'09
6:06 a.m.
On Mon, May 18, 2009 00:50, Fons Adriaensen wrote:
On Sun, May 17, 2009 at 06:37:27PM +0100, Rui Nuno
Capela wrote:
fwiw, qjackctl calls jack_client_open() with the *JackNoStartServer*
option flag set.
iow, qjackctl should never invoke the jackd auto-start feature. if it ever
starts jackd, it starts explicitly with its own fork+exec method (ie.
QProcess::start()).
so, and i'm just guessing, it is the jackdbus devil stack that is pushing
the jackd auto-starting into our throats, with complete disrespect with
what's in the official jack api (i supect it doesn't give a damn to a
legitimate JackNoStartServer option:).
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
can you explain a bit what is supposed to be
"the right jackd"?
OK. The 'right' one is the one that qjackctl is configured
for, also the one specified in ~/jackdrc. It uses the Terratec EWT88 card
which is hw:1.
The 'wrong' one is using the on-board Intel stuff which
is hw:0.
1. I accidentally start a jackified app without a server
running. This autostarts the wrong jackd. Jackd seems to ignore ~/.jackdrc.
2. No problem, this jackd had the -T option, when I stop
the application then the jackd is gone as well.
Without dbus all is ok afterwards. But with dbus:
3. I start qjackctl. It immediately shows a running
jackd (** there was none before, so running qjackctl started it **). This
jackd is the 'wrong' one.
4. Stopping and starting in qjackctl does not help,
this always starts the 'wrong' one. Qjackctl's setup window still shows the
'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill a daemon created by the
dbus stuff.
afaict, qjackctl starts jackd with the exact
argument parameters as
given in its setup dialog, no more, no less, no guessing.
Not is this case.