11 Dec
2007
11 Dec
'07
10:25 a.m.
Krzysztof Foltman <wdev(a)foltman.com> writes:
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.
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).
Looks like temporary debug hack that got way into trunk.
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.
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.
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
expat?
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>
* 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. * Provide
access to clock source parameter (tricky)
What would it return? A driver and sound device ID? * Provide
access to debug-timer parameter (not fully documented -
optarg)
What's a debug-timer? * 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". * 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? 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? 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...?