Attached are two patches:
* The logs patch replaces various calls to fprintf(),printf() and
fputs() with calls to jack_error() and newly appeared jack_info()
functionality. It also fixes some obvious error/info log mismatches
in current code.
* 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.
D-Bus patch requires logs patch. As currently exported it also requires
midi-alsa-munge patch, but this is not real requirement.
So patch apply order is (against latest svn, tested with r1070):
* jackd-midi-alsa-munge-r1051.patch (p0)
* jack-logs-20071209-r1070.patch (p1)
* jack-dbus-20071209-r1070.patch (p1)
What is not implemented yet:
* Provide access to clock source parameter (tricky)
* Provide access to debug-timer parameter (not fully documented -
optarg)
* Send signals to (control) apps (status changes, connections, clients,
port renames, xruns, error and info logs)
* In client library, when compiled with dbus support, try to start via
dbus frontend first (auto-activation)
* Implement configurator supporting multiple user configurations
(separate D-Bus object)
D-Bus patch currently requires dbus-glib for main code and libxml2 for
settings persistence. Applying patch enables configure time checks for
required libraries and if they are not present, corresponding feature is
not built.
Currently there is problem with ffado driver (freebob works). libffado
uses libxml++ that uses libxml2. libxml2 has quite lot of global
things, Including global hooks used by libxml++ and initialized in
constructor global object. To avoid crashes when ffado driver is
available, it is ignored by the jackdbus frontend (it is still available
in jackd). This is temporary solution. I could of course don't use
libxml2 but this will only delay effect in ffado driver until some other
driver is starts using libxml2.
After compiling and installing jackdbus, you will get also a small
python app, jack_control that allows accessing of jackdbus. jack_control
is test app, and while quite usable is not supposed to be in line with
full-featured jack control apps like qjackctl and patchage.
Theory of operation:
JACK server works in background with log file and settings preserved in
~/.jackdbus/ directory. jack controller dbus object is autoactivated
when accessed. Thus jack server works in background while allowing to
access it post factum, either logs, settings or start/stop.
Multiconfig functionality is provided by separate object to be reused by
control apps like patchage and qjackctl. All of them will reuse jack
presets and user will get transparent workflow.
If they adapt it. Dave, Rui?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>