17 May
2009
17 May
'09
11:10 a.m.
Fons Adriaensen wrote:
On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno
Capela wrote:
unfortunately, Qt4's class which is being used for wrapping the jackd
process (QProcess) does kill it on its destructor. afaict, this behavior
wasn't present in Qt3 and that's why there's no option to keep jackd
running upon quitting qjackctl anymore.
qjackctl only writes to ~/.jackdrc *iif* you opt
to (see Setup/Misc/Save
JACK audio server configuration). otherwise it *never* makes use of that
file ie. it never auto-starts jackd implicitly; it only does start jackd
explicitly if none is found running atm.
If the file is ignored by jackd, and by qjackctl, why
does qjackctl write it at all ?
if you really want several jackd server running
simultaneously
I don't want that. I want to get rid of one that was
started automatically, terminated, but restarted by
dbus (why on earth ?) when I run qjackctl. The net
result is that running qjackctl starts a server with
parameters that have no relation at all to its setup
(making it appear as if qjackctl has gone nuts), and
starting the one corresponding to qjackctl's setup
becomes impossible. It's very probably not qjackctl's
fault.
Two other things _are_:
1. I definitely want to be able to terminate qjackctl
without stopping jackd, even if that jackd was started
by qjackctl. This used to be possible.
2. Qjackctl-0.3.4 seems to have a bug handling the
port
creation and destruction callbacks, it continues to show
ports that have been deleted and does not show some new
ones. This happens when the delete/create calls are close
together. Jack_evmon shows the right events in the right
order, so it must be qjackctl getting it wrong.
this might just be a side-effect of the jack_port_t* reuse issue that i
think has been discussed recently.
qjackctl does not handle port (un)registration callbacks but does its
book-keeping with this jack_port_t * handle as a unique key identifier.
if, for instance, one client unregisters one given port and registers
another in a quick sequence, it might just happen that the new port has
the very same jack_port_t* address value which got just reclaimed and
reused. alas, qjackctl assumes it's the very same port object as it
keeps jack_port_t*s as its unique port identifiers, so nothing changes.
i suppose i'll have to fix this soon. by properly handling port
unregistration callbacks, which will be a novelty after 5+ years of
doing just fine without on jack1 at least ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org