[LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov nedko at arnaudov.name
Tue Dec 11 14:30:28 UTC 2007

Krzysztof Foltman <wdev at foltman.com> writes:

>>  * The dbus patch provides additional fronted to jack server, alternative
>>    to jackd. the dbus object is auto activatated when
>>    needed. Starting and stopping of the jack server are methods of the
>>    dbus object. Other methods are for setting/getting jack
>>    settings. Settings are being persisted.
> I wish it worked like that from start. Seamless integration with desktop
> is always nice. Qjackctl was a step in the right direction and I'm using
> it very often, but this, plus a dockable or tray-based control app,
> would be even better.

My personal plan incudes creation of window maker style dockapp with
feature of launching full featured control app like patchage. In fact i
see 3 things that i want to do with jack:
 * monitor jack server status (started/stopped)
 * show jackdbus log file (to inspect what happens actually) - probably
   using external app
 * manage connections - external app should be used for this
 * start/stop server - can be feature of the dockapp itself
 * manage configuration - external app should be used for this

all external apps should be configurable.

If someone has interest to cooperate app can be done as tray icon too.

>>  * Provide access to clock source parameter (tricky)
> What would it return? A driver and sound device ID?

From my knowledge, clock source is internal thing that is global and not
per engine. Thus I've not exported it as engine parameter. Choosing the
way depends on how it actually works, something i'm not aware
yet. Having different engines (servers) to use different clock sources
is probably the right way (if possible at all).

>>  * Provide access to debug-timer parameter (not fully documented -
>>    optarg)
> What's a debug-timer?

Looks like temporary debug hack that got way into trunk.

>>  * In client library, when compiled with dbus support, try to start via
>>    dbus frontend first (auto-activation)
> Auto-activation and auto-shutdown is definitely a good idea as well. At
> least, if we want JACK to "just work".

I made that work yesterday. If libjack is compiled with dbus support
before trying jackd launch, it will try to start server through dbus. So
if dbus is available not working for some reason, it should still work.

>>  * Implement configurator supporting multiple user configurations
>>    (separate D-Bus object)
> Do you mean switchable or simultaneous configs? Switchable, I suppose?
> Yes, that would be useful as well. Is it how sampling frequency
> selection would work?

switchable configs. changing sample rate on the fly is not a goal of
jackdbus by itself. I have no plans to work on that. You could have
different configs for different sample rates of course.

>> Currently there is problem with ffado driver (freebob works). libffado
>> uses libxml++ that uses libxml2.
> Do you *need* XML support at all? Can't it be done with something
> simpler, like plain text config?

Using self crafted code for that is the path to hell with having bugs in
it. Do you think there are real systems using jack without libxml nor

>> Multiconfig functionality is provided by separate object to be reused by
>> control apps like patchage and qjackctl.
> How does multiconfig relate to LASH? Is jackdbus configuration name
> stored in LASH session, or...?

My initial plan is either this or even better, also store jack settings
(like sample rate) in lash session. And give user choices when restoring
session with jack configuration not matching current one (session moved
to another machine for example).

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/20071211/5355aa29/attachment.pgp>

More information about the Linux-audio-dev mailing list