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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
