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

[Nedko Arnaudov]

Fons Adriaensen <fons at kokkinizita.net> writes:

> On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
>
>> You have installed jack package that does not work well with
>> qjackctl (dbus enabled one). Your application autostarted jack server
>> through dbus.
>
> It did not. No jack app here uses dbus.

If i got it right (dbus enabled libjack.so) then every jack app on your
machine uses dbus.

>> jackdrc style commandline options for jackd are for jackd. They are not
>> used for jackdbus. They cant be used for jackdbus. Because of the object
>> activation works in all distributed object systems I know. This includes
>> DCOM and D-Bus.
>
> What nonsense it this ? Everybody here tells me that 
> the dbus support is build on top of the existing C
> API and nothing else, that it just a communication
> layer allowing you to access the C API.  Hence jackd
> is the same with dbus or without. Or isn't this true,
> and is the dbus support much more invasive than some
> people want to admit ?

I dont get what you are talking about. Please explain.

> The client that autostarted a jackd did not use dbus.
> When I later started qjackctl it did not use dbus.

libjack.so will not start jackd if compiled in dbus. Actually it can but
only if jack server start through dbus failed. Obvisouly it didnt
because you said that it got started with wrong arguments, right?

> Yet the 'jackdbus auto' daemon (which nobody needed
> since all apps use the C API, but started anyway)
> interferes with clients not using dbus at all.

again if you have jackdbus enabled libjack.so all your clients DO
interact with dbus.

> Are you trying to say that on a jack+dbus system
> *all* jack apps have to be dbus-aware (or fail) ?

NO. dbus knowledge is behind libjack. But yes, they load libdbus.so when
they are started. Maybe you want to verify that with ldd?

>> So you complain about qjackctl missing support for jackdbus? Having that
>> will be nice :)
>
> Is that supposed to be funny ? 

Yes :)

> Final remark: the dbus advocates here are seriously
> contradicting themselves.
>  
> 1. Dbus is just a communication layer.

no

it is distributed object model. this somewhat bigger than IPC.

> 2. Dbus adds functionality that can't be
>    provided via the normal interfaces.

and no again

It can be added. You can reinvent the wheel. You can reuse other already
invented mechanism. D-Bus was choosen because it is already quite
widespread in Linux systems.

> Both can't be true at the same time.

they are both false but even if they were true they can be both true,
according to my understanding of logic :D if A and B are not corelated
then A and B can be true at the same time.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090518/2273de93/attachment.pgp>