3 Oct
2009
3 Oct
'09
9:03 a.m.
Patrick Shirkey wrote:
On 10/03/2009 05:02 AM, Jens M Andreasen wrote:
fyi:
this new dbus thing in qjackctl is NOT related what-so-ever with
jackdbus or any intrinsic jackd/pulseaudio dbus ipc facility.
the new qjackctl dbus thing is just about controlling qjackctl itself,
i'll repeat, qjackctl and NOT jackd. although it controls the later
indirectly as the former was devised to get access to the qjackctl
"start" and "stop" service functions from outsiders, eg. from an
external script or user process--in fact, it was primarily suggested to
make it easy for integration with suspend/resume scripts.
thus, you can start the qjackctl controlled service by issuing the
following command:
dbus-send --system / org.rncbc.qjackctl.start
and stopping with:
dbus-send --system / org.rncbc.qjackctl.stop
sure enough, you can disable it at build/configure time:
./configure --disable-dbus
hth
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Wed, 2009-09-30 at 19:58 +0100, Rui Nuno
Capela wrote:
Surely this particular issue can be disabled?
Dbus support is critical to making sure jack2 and pulse audio work
together ootb without having to use a workaround loader script.
I thought, I also read that it's a compile time option too so if you
don't particularly want it then you can disable dbus support in qjackctl
before starting.
- A couple of primitive D-Bus interface slots
have been introduced ...
Can somebody give a pointer to why D-Bus is desireable in an
RT-envoronment? What is the magic we do not wan't to live without?
I am asking this because I am experiencing that the 'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
That it at times takes more than five seconds to open a window
displaying only a handful of bytes (locally available), tells me that
something is not working excactly as intended.
Oh! BTW: Why am I revealing this kind of information about local
activity to my ISP in the first place?