9 Dec
2007
9 Dec
'07
3:31 p.m.
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>
9 Dec
9 Dec
5:43 p.m.
On Dec 9, 2007 9:35 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
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)
And here comes the ebuild for those adventurous gentoo users out there
who want to try this baby out ! :-)
Right now it does not respect dependencies though, use with caution
and uninstall the regular jack package by hand first.
Now for some comment on these patches, I've been playing a bit with
that jack_control thingy. Configuring and starting jack has never been
so easy...
Enjoy,
__________________
Marc-Olivier Barre,
MarcO'Chapeau.
10 Dec
10 Dec
12:03 p.m.
On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov wrote:
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.
I proposed this ages ago and Paul called it 'bloat' :)
Multiconfig functionality is provided by separate
object to be reused by
control apps like patchage and qjackctl.
I don't understand what this means in concrete terms. Simple example?
All of them will reuse jack
presets and user will get transparent workflow.
If they adapt it. Dave, Rui?
Hm.. if the connection and new client/port callbacks are mapped to dbus
messages (jack-dbus -> client) it would be possible to implement things
like qjackctl/patchage/lash without a dependency on libjack at all.
Nice...
-DR-
12:13 p.m.
On Mon, 2007-12-10 at 12:03 -0500, Dave Robillard wrote:
On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov
wrote:
see what happens when you ask nicely? :))
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.
I proposed this ages ago and Paul called it 'bloat' :)
16 Dec
16 Dec
8:01 p.m.
On Mon, 2007-12-10 at 12:12 -0500, Paul Davis wrote:
On Mon, 2007-12-10 at 12:03 -0500, Dave Robillard
wrote:
Bah! I only get nasty /after/ the rejection part :)
-DR-
On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov
wrote:
see what happens when you ask nicely? :)) 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.
I proposed this ages ago and Paul called it 'bloat' :)
10 Dec
10 Dec
1:14 p.m.
Dave Robillard <dave(a)drobilla.net> writes:
Apps like patchage and qjackctl access the multiconfig object with
interface (quick draft):
* get_presets() - return available presets names
* new_preset() - add new preset
* remove_preset() - remove existing preset
* set/get of preset settings: engine options, selected driver, driver
options of selected driver
That object will presist its settings in XML configuration file. I've
made example one available here:
http://nedko.arnaudov.name/soft/jack/jack.xml
or here:
http://triton.atia.com/nedko/soft/jack/jack.xml
This file is not acessed by control apps directly. Object methods are
used instead (see above).
Also either autosave mode (settings persistence) and manual save may be
viable. What will get implemented will probably be shaped by people in
charge of existing control apps (qjackctl,patchage). So put your
opinions please.
This is the plan. We will need that for lash on dbus too (I want lash
to control jack server not vice versa). libjack interface is still
available as alternative method (dbus is not available on MacOSX by
default).
Speaking of MacOSX, I saw that there is fink package for D-Bus. It may
be worth for someone with Tiger/Leopard JACK audio setup to check how
well fink dbus package works with jackdbus.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov
wrote:
logs patch has taken some direct directions from Paul that I followed
with fate that this will ease its way to jack trunk (pre 1.0).
Paul and others in charge, what you think?
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.
I proposed this ages ago and Paul called it 'bloat' :) Multiconfig
functionality is provided by separate object to be reused by
control apps like patchage and qjackctl.
I don't understand what this means in concrete terms. Simple example? All of them
will reuse jack
presets and user will get transparent workflow.
If they adapt it. Dave, Rui?
Hm.. if the connection and new client/port callbacks are mapped to dbus
messages (jack-dbus -> client) it would be possible to implement things
like qjackctl/patchage/lash without a dependency on libjack at all.
Nice... 
1:46 p.m.
Nedko Arnaudov wrote:
Dave Robillard <dave(a)drobilla.net> writes:
Apps like patchage and qjackctl access the multiconfig object with
interface (quick draft):
* get_presets() - return available presets names
* new_preset() - add new preset
* remove_preset() - remove existing preset
* set/get of preset settings: engine options, selected driver, driver
options of selected driver
That object will presist its settings in XML configuration file. I've
made example one available here:
http://nedko.arnaudov.name/soft/jack/jack.xml
or here:
http://triton.atia.com/nedko/soft/jack/jack.xml
This file is not acessed by control apps directly. Object methods are
used instead (see above).
Also either autosave mode (settings persistence) and manual save may be
viable. What will get implemented will probably be shaped by people in
charge of existing control apps (qjackctl,patchage). So put your
opinions please.
>> All of them will reuse jack
>> presets and user will get transparent workflow.
>> If they adapt it. Dave, Rui?
eh... right, now that qjackctl is having a free ride on windows we can
put it back where it belongs :)
this d-bus interface seems a good idea nevertheless, and now that kde4
is almost on the brink, it sounds logical to push it as duct tape for
phonon and jack, eh?
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov
wrote:
logs patch has taken some direct directions from Paul that I followed
with fate that this will ease its way to jack trunk (pre 1.0).
Paul and others in charge, what you think?
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.
I proposed this ages ago and Paul called it 'bloat' :)
Multiconfig functionality is provided by separate object to be reused by
control apps like patchage and qjackctl.
I don't understand what this means in
concrete terms. Simple example? 
2:10 p.m.
Am Montag, 10. Dezember 2007 schrieb Rui Nuno Capela:
this d-bus interface seems a good idea nevertheless,
DBUS seems to be very cool, yes.
and now that kde4 is almost on the brink, it sounds
logical to push it as
duct tape for phonon and jack, eh?
No, never. See the endless discussions on kde-multimedia and lau.
KDE needs a multimedia-server/-framework [*]. jack is _not_ what kde needs
because jack does neither video nor decoding of compressed formats.
And I really don't understand how you want to duct phonon and jack by dbus: Do
you want to sent audio data via dbus? Is dbus even capable of these
data-rates?
Arnold
[*] And because relying on just one framework/server has proven to be a bad
thing, phonon is "just" an abstraction-layer between the apps wanting a
stable api and frontends supporting all the nifty things.
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
2:22 p.m.
Arnold Krille wrote:
Am Montag, 10. Dezember 2007 schrieb Rui Nuno Capela:
to my knowledge, phonon is in need of a jack backend, as gstreamer, as
pulseaudio, or maybe through xine. what i thought is is not about to let
jack be the kde4 audio server, no. i was just thinking about
configuration control, not the audio streaming per se.
this d-bus interface seems a good idea
nevertheless,
DBUS seems to be very cool, yes.
and now that kde4 is almost on the brink, it
sounds logical to push it as
duct tape for phonon and jack, eh?
No, never. See the endless discussions on kde-multimedia and lau.
KDE needs a multimedia-server/-framework [*]. jack is _not_ what kde needs
because jack does neither video nor decoding of compressed formats.
And I really don't understand how you want to duct phonon and jack by dbus: Do
you want to sent audio data via dbus? Is dbus even capable of these
data-rates?
[*] And because relying on just one framework/server has proven to be a bad
thing, phonon is "just" an abstraction-layer between the apps wanting a
stable api and frontends supporting all the nifty things.
yes, right.
cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2:44 p.m.
hi Rui,
Rui Nuno Capela schrieb:
Arnold Krille wrote:
GStreamer has a jacksink, unfortunately the jacksrc ist still missing ...
Am Montag, 10. Dezember 2007 schrieb Rui Nuno
Capela:
to my knowledge, phonon is in need of a jack backend, as gstreamer, as
pulseaudio, or maybe through xine. what i thought is is not about to let
jack be the kde4 audio server, no. i was just thinking about
configuration control, not the audio streaming per se. this d-bus interface seems a good idea
nevertheless,
DBUS seems to be very cool, yes.
and now that kde4 is almost on the brink, it
sounds logical to push it as
duct tape for phonon and jack, eh?
No, never. See the endless discussions on
kde-multimedia and lau.
KDE needs a multimedia-server/-framework [*]. jack is _not_ what kde needs
because jack does neither video nor decoding of compressed formats.
And I really don't understand how you want to duct phonon and jack by dbus: Do
you want to sent audio data via dbus? Is dbus even capable of these
data-rates?
[*] And because relying on just one
framework/server has proven to be a bad
thing, phonon is "just" an abstraction-layer between the apps wanting a
stable api and frontends supporting all the nifty things.
yes, right.
cheers.
3:13 p.m.
Am Montag, 10. Dezember 2007 schrieb Rui Nuno Capela:
Arnold Krille wrote:
Well, everyone is free to write backends for phonon. If you want, you can even
try to write a phonon-backend that does jack. But: What do you use for
video[*]? Rely on xine or gstreamer? Then you can just use the xine-backend
for phonon...
jack (as in professional low-latency audio) and phonon (as in generic
multimedia framework) are two different things. I don't think mixing them can
be done easily. And I don't think it is good to try to.
Arnold
[*] A multimedia framework does more then audio, it does video as well. And
that is why phonon afaik requires a backend to have video-support too.
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
Am Montag, 10. Dezember 2007 schrieb Rui Nuno
Capela:
to my
knowledge, phonon is in need of a jack backend, as gstreamer, as
pulseaudio, or maybe through xine. and now that kde4 is almost on the brink, it
sounds logical to push it
as duct tape for phonon and jack, eh?
No, never. See the endless discussions on
kde-multimedia and lau.
KDE needs a multimedia-server/-framework [*]. jack is _not_ what kde
needs because jack does neither video nor decoding of compressed formats.
2:50 p.m.
Arnold Krille <arnold(a)arnoldarts.de> writes:
And I really don't understand how you want to duct
phonon and jack by dbus: Do
you want to sent audio data via dbus? Is dbus even capable of these
data-rates?
No! libjack is and what should be used for actual data transfers
(audio,midi,video?). With jacdbus, dbus is used for control type of
information like configuring jack server, starting stopping it, managing
and monitoring connections, etc.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
3:16 p.m.
Am Montag, 10. Dezember 2007 schrieb Nedko Arnaudov:
Arnold Krille <arnold(a)arnoldarts.de> writes:
Yeah, I know what dbus is for. But phonon is not a lib to control, its a lib
to send audio and video around. So if you want to duct phonon and jack via
dbus it implies that you send audio via dbus from phonon to jack and vice
versa. Stupid, I know. But thats what Rui seemed to say. :-)
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
And I really don't understand how you want to
duct phonon and jack by
dbus: Do you want to sent audio data via dbus? Is dbus even capable of
these data-rates?
No! libjack is and what should be used for actual data transfers
(audio,midi,video?). With jacdbus, dbus is used for control type of
information like configuring jack server, starting stopping it, managing
and monitoring connections, etc. 
11 Dec
11 Dec
12:52 a.m.
On Monday 10 December 2007 21:54:45 Nedko Arnaudov wrote:
Arnold Krille <arnold(a)arnoldarts.de> writes:
And perhaps including an interface to tell clients to load presets/patches,
like lash does now?
J
And I really don't understand how you want to
duct phonon and jack by
dbus: Do you want to sent audio data via dbus? Is dbus even capable of
these data-rates?
No! libjack is and what should be used for actual data transfers
(audio,midi,video?). With jacdbus, dbus is used for control type of
information like configuring jack server, starting stopping it, managing
and monitoring connections, etc.
5:33 a.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
On Monday 10 December 2007 21:54:45 Nedko Arnaudov
wrote:
With planned lash reimplementeation over dbus - yes. But this is by no
means a jackdbus task. jackdbus presets (multiconfig object) are just
way to have multiple presets for jack stored transparently. OTOH, lash
could not really treat jack server as regular app, because it knows that
jack server is the thing that makes connections between apps.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Arnold Krille <arnold(a)arnoldarts.de>
writes:
And perhaps including an interface to tell clients to load presets/patches,
like lash does now? And I really don't understand how you want to
duct phonon and jack by
dbus: Do you want to sent audio data via dbus? Is dbus even capable of
these data-rates?
No! libjack is and what should be used for actual data transfers
(audio,midi,video?). With jacdbus, dbus is used for control type of
information like configuring jack server, starting stopping it, managing
and monitoring connections, etc. 
8:58 a.m.
Nedko Arnaudov wrote:
* 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.
Good idea. Using printf() and friends as means of communicating status
is good for prototype code, but some error message "framework" (like
this one) is usually better - more flexible, easier to maintain etc.
* 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?
* Send signals to (control) apps (status changes,
connections, clients,
port renames, xruns, error and info logs)
That's a must! :)
* 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...?
Krzysztof
9: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...? 
5:27 p.m.
Nedko Arnaudov wrote:
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).
Clock source is defined by the server and information about it is shared
to each client (through engine control shm block; jack_control_t). All
related instances have to use the same clock source.
Each instance then calls jack_set_clock_source() to set up function
pointer to the correct clock source (sometimes os and hw specific). This
is global per-instance variable. Applications also call this through
jack_get_microseconds().
jack_get_microseconds() is trying to provide as accurate as possible
monotonic clock with lowest possible overhead.
BR,
- Jussi Laako
5982
days inactive
5989
days old
linux-audio-dev@lists.linuxaudio.org
17 comments
10 participants
participants (10)
-
Arnold Krille -
Dave Robillard -
Jussi Laako -
Juuso Alasuutari -
Krzysztof Foltman -
Marc-Olivier Barre -
Nedko Arnaudov -
Paul Davis -
Rui Nuno Capela -
Stefan Kost