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.
> 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 ?
The client that autostarted a jackd did not use dbus.
When I later started qjackctl it did not use dbus.
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.
Are you trying to say that on a jack+dbus system
*all* jack apps have to be dbus-aware (or fail) ?
> So you complain about qjackctl missing support for jackdbus? Having that
> will be nice :)
Is that supposed to be funny ?
Final remark: the dbus advocates here are seriously
contradicting themselves.
1. Dbus is just a communication layer.
2. Dbus adds functionality that can't be
provided via the normal interfaces.
Both can't be true at the same time.
Ciao,
-- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Mon May 18 20:15:08 2009
This archive was generated by hypermail 2.1.8 : Mon May 18 2009 - 20:15:08 EEST