[LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

Danni Coy danni.coy at gmail.com
Wed May 20 03:05:51 UTC 2009


On Wed, 20 May 2009 07:32:51 am Dan Mills wrote:
> On Tue, 2009-05-19 at 21:03 +0200, Fons Adriaensen wrote:
> > Both are examples of braindead ways to do things,
> > both originate from the same source. Dbus ties
> > jackd to the desktop and is just one more example
> > of the same insane evolution.
>
> Indeed.
>
> I might be way off base, but what is wrong with the old school approach
> to changing daemons settings by getting it to re read a config file on
> SIGUSR1?
>
> Handle stdout by providing a couple of arguments that specify where
> to write the output (Think named pipes setup by whatever control
> interface cares).
>
> Dbus & XML for what should be a minimal system daemon running with RT
> priority? WTF?

The daemon itself is still a minimal system with  RT priority. The part that 
has changed is the control part - which doesn't run with RT Priority. (that is 
my understanding anyways). This will not affect app developers unless your app 
tries to control jack. That means qjackctl, patchage and applicitions that try 
to start jack if they can't find it (ardour, others?) some of the command line 
utilities like jack connect.

DBus is designed in such a way that it makes communicating with graphical 
applications easy but I am not aware of any dependence on a graphical 
environment. You can commands to  a dbus aware application on the command line 
via the use of the dbus-send command this can be incorporated into shell 
scripts and the like.  The syntax is bit verbose you can get some idea by 
using the dbus-monitor command to see what is being sent currently by your 
system.

Pretty much all modern Linux systems use HAL + DBus + udev to configure 
hardware (especially finding new hardware that is plugged into a running 
system). Unless you are specifically removing this functionality then dbus will 
be on your system and running what is known as the 'system bus' whether you 
are in a graphical shell or a text based one.  

I would like to know what specific configurations Fons is working with and what 
specific objections he has to dbus - at the moment it sounds more emotive than 
objective. Is the objection the overhead of running a dbus session bus,  That 
dbus has some specific limitations that the existing jack control methods don't 
have or is it that the current system is working perfectly and no change is 
necessary. Learning new ways of doing things takes time and effort.

As far as I can see the specific problem occurred because somebody used an 
experimental package on a distro (the official jack version on Jaunty the 
current Ubuntu release unless I am very  much mistaken is not a jack2 
version).  This package specifically contained the dbus version of jack which 
is not the recommended version. This version would not play with a graphical 
app that does not understand the dbus version of jack.

Presumably the dbus version is only really for testing at the moment and 
should only really find it's way into most users hands once the whole toolchain 
is there.  Once that happens it shouldn't make a real difference to the 
majority of users other than the config file being moved from one place to 
another and the format changing. For which I suggest a command line utility 
that can explicitly be used to convert the current file format to the new one.

Users who have written a large amount of custom shell scripts may be affected. 
But I haven't heard anything about tools like jack-connect being removed and 
even if that were the case it would be pretty easy to replace them with shell 
scripts that use the dbus-send command.

If Jack is not broken and doesn't need fixing. 

Why can't I stop jack reconfigure it and have all my jack apps auto-reconnect 
when the jack server comes back up. (or better yet - reconfigure the server 
without stopping it).

Why can't I take a snapshot of everything running in jack and have be able to 
recall that snapshot including applications, connections, files that were open 
and positions within those files. KDE has been able to do this for the most 
part for a long time now (connections don't make sense in KDE and documents 
and positions only works in apps that support this ).  In short why doesn't 
LASH work satisfactorily yet? I know I can write scripts to achieve a lot of 
that really isn't the best solution in this case. It's a good solution for 
setting up a general pipeline for creating music. But not for loading up an 
individual song  you are working on. Unless you use exactly the same process 
for each song.

Why can't I specify which ports to autoconnect to including no ports?


-- 
The fellow sat down at a bar, ordered a drink and asked the bartender if he
wanted to hear a dumb-jock joke.
	"Hey, buddy," the bartender replied, "you see those two guys next to
you?  They used to be with the Chicago Bears.  The two dudes behind you made
the U.S. Olympic wrestling team.  And for your information, I used to play
center at Notre Dame."
	"Forget it," the customer said.  "I don't want to explain it five
times."




More information about the Linux-audio-dev mailing list