19 May
2009
19 May
'09
6:42 a.m.
Hi All,
After hours of discussion on #jack IRC, it seems that we are in a
completely blocked situation:
1) we currently have 2 "incarnations" of the jack server named "jackd"
and "jackdbus". "jackd" is the legacy "classic" version of
the server
that interact with the ~/jackdrc setting file. This setting file may
be written by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware
version of the server, it use a completely new setting management
system using a "conf.xml" file. Il may use a multi-setting system in
the future.
2) the *heart" of the problem Fons initially told about is in the way
applications "auto-start" the server. This launching strategy is part
of libjack and depends of the incarnation of the server (jackd of
jackdbus) that is supposed to be used. Right now this strategy is
chosen at *compile time*, so that in "classic" mode the "jackd" server
will be launched using a fork-exec strategy, or in D-Bus mode the
"jackdbus" server will be launched by issuing a D-Bus call.
3) Since the "auto-start" strategy is chosen at compile time and thus
is coded in libjack, users will typically encounter all sort of
problems as soon as the used applications interact with a "D-Bus based
strategy" libjack (that will launch "jackdbus" incarnation) and users
still use Qjackctl that interact with the "jackd" incarnation.
4) Different ideas have been proposed to merge the 2 "jackd" and
"jackdbus" incarnations in a unique extended "jackd" exe, but nothing
really clear emerged.
4) A possible proposed solution was to define 2 completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....). The problem of this strategy is that..., it is a kind
of complete failure regarding the way jack is supposed to be
distributed. It may even get worse if a new "jackosc" incarnation (a
one that would allow to control the server using OSC) appears a some
point in the future...
5) Another idea would be improve the "choice of auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once
globally for a
given working session...
5) Another idea would be be to completely drops the "auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Comments?
Stephane
19 May
19 May
7:29 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 09:38, Stéphane Letz wrote:
Hi All,
After hours of discussion on #jack IRC, it seems that we are in a
completely blocked situation:
1) we currently have 2 "incarnations" of the jack server named
"jackd"
and "jackdbus". "jackd" is the legacy "classic" version of
the server that
interact with the ~/jackdrc setting file. This setting file may be written
by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware version of the
server, it use a completely new setting management system using a
"conf.xml" file. Il may use a multi-setting system in
the future.
2) the *heart" of the problem Fons initially told about is in the way
applications "auto-start" the server. This launching strategy is part of
libjack and depends of the incarnation of the server (jackd of jackdbus)
that is supposed to be used. Right now this strategy is chosen at *compile
time*, so that in "classic" mode the "jackd" server will be launched
using
a fork-exec strategy, or in D-Bus mode the "jackdbus" server will be
launched by issuing a D-Bus call.
3) Since the "auto-start" strategy is chosen at compile time and thus
is coded in libjack, users will typically encounter all sort of problems as
soon as the used applications interact with a "D-Bus based strategy"
libjack (that will launch "jackdbus" incarnation) and users still use
Qjackctl that interact with the "jackd" incarnation.
4) Different ideas have been proposed to merge the 2 "jackd" and
"jackdbus" incarnations in a unique extended "jackd" exe, but
nothing
really clear emerged.
4) A possible proposed solution was to define 2 completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be used
with it. The "D-Bus" one would package the "jackdbus" incarnation,
and
provide D-Bus bas control applications (patchage, ladi tools....). The
problem of this strategy is that..., it is a kind of complete failure
regarding the way jack is supposed to be distributed. It may even get
worse if a new "jackosc" incarnation (a one that would allow to control
the server using OSC) appears a some point in the future...
5) Another idea would be improve the "choice of auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once
globally for a given
working session...
5) Another idea would be be to completely drops the "auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Comments?
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring
.jackdrc if it exists on your home directory. ie. if .jackdrc exists then
do the "classic" auto-start; if not, check d-bus service; etc.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
7:36 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring
.jackdrc if it exists on your home directory. ie. if .jackdrc exists
then
do the "classic" auto-start; if not, check d-bus service; etc.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
But since some applications like Qjackctl or Ardour write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
Stephane
7:42 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 19 May 2009 11:32:37 +0200
Stéphane Letz <letz(a)grame.fr> wrote:
I also think that the existence of a file is a bad way to determine
classic or dbus or whatever might show up in future.
Some env variable or similar would be a lot better, but it's also
important that this doesn't interfere with the manual start of jackd in
any way, so you can have it autostart with dbus, kill it, start it
manually without dbus.
Regards,
Philipp
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring
.jackdrc if it exists on your home directory. ie. if .jackdrc
exists then
do the "classic" auto-start; if not, check d-bus service; etc.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
But since some applications like Qjackctl or Ardour write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
Stephane
9:04 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Some env variable or similar would be a lot better, but it's also
important that this doesn't interfere with the manual start of jackd
in
any way, so you can have it autostart with dbus, kill it, start it
manually without dbus.
Regards,
Philipp
_______________________________________________
Concerning implementation, we already have a "JACK_NO_START_SERVER"
env variable that allows to globally disable the auto-start feature.
We could possibly define a new "JACK_AUTOSTART_MODE" (or whatever)
that could take "classic", "dbus" or "osc"...
Stephane
8:37 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 10:32, Stéphane Letz wrote:
qjackctl can already opt to not write any .jackdrc. ardour may vary. i
would assume it to use the jack control api in a near future. the same
would apply to qjackctl. then everybody will be happy again ;)
i was asking for a default strategy, call it "auto", which will try
"classic" first, then "d-bus", then whatever.
the main question, at least in my mind, is all about *which* settings will
be used to auto-start the server, isn't it? an explicit command line, as
in "classic", should *always* take precedence over the settings in any
internal configuration database, which i think the "d-bus" honors instead
and that latter behavior is being the root of all "d-bus" evil. scnrt ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring .jackdrc if it exists on your home directory. ie. if .jackdrc
exists then do the "classic" auto-start; if not, check d-bus service;
etc.
byee --
rncbc aka Rui Nuno Capela rncbc(a)rncbc.org
But since some applications like Qjackctl or Ardour write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
9 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Le 19 mai 09 à 12:37, Rui Nuno Capela a écrit :
On Tue, May 19, 2009 10:32, Stéphane Letz wrote:
qjackctl can already opt to not write any .jackdrc. ardour may vary. i
would assume it to use the jack control api in a near future. the same
would apply to qjackctl. then everybody will be happy again ;)
i was asking for a default strategy, call it "auto", which will try
"classic" first, then "d-bus", then whatever.
the main question, at least in my mind, is all about *which*
settings will
be used to auto-start the server, isn't it? an explicit command
line, as
in "classic", should *always* take precedence over the settings in any
internal configuration database, which i think the "d-bus" honors
instead
and that latter behavior is being the root of all "d-bus" evil.
scnrt ;)
cheers
--
My feeling is that is we choose the runtime auto-start strategy, then
we should not mix anything concerting setting management. Each
"incarnation" of server has it's own view of setting management and
this has to stay completely separated from any other view. If the used
chose "classic" auto-start strategy (that would stay the default yes)
then he is supposed to know that he has to use "classic" control tools
(Qjackctl..). If the user chose "D-Bus" auto-start strategy, then he
knows he has to use D-Bus aware control tools only and so on...
Stephane
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring .jackdrc if it exists on your home directory. ie.
if .jackdrc
exists then do the "classic" auto-start; if not, check d-bus
service;
etc.
byee --
rncbc aka Rui Nuno Capela rncbc(a)rncbc.org
But since some applications like Qjackctl or Ardour write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
11:08 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Stéphane Letz wrote:
Le 19 mai 09 à 12:37, Rui Nuno Capela a écrit :
While this may work in the short term in terms of saving valuable
resources for other more important tasks I think you already know that
is in not acceptable in the medium to long term as it will just confuse
the f out of the "average" user requiring them to know the difference
between the competing standards. Tooltips might help here but there are
plenty who don't know how to read a tooltip also.
However if the goal is to have this problem completely fixed and
transparent before the average user is expected to use the system then
proceed as outlined above as it is reasonable from an end user pov to
set limits as such in the short term.
--
Patrick Shrkey
Boost Hardware Ltd.
On Tue, May 19, 2009 10:32, Stéphane Letz wrote:
qjackctl can already opt to not write any .jackdrc. ardour may vary. i
would assume it to use the jack control api in a near future. the same
would apply to qjackctl. then everybody will be happy again ;)
i was asking for a default strategy, call it "auto", which will try
"classic" first, then "d-bus", then whatever.
the main question, at least in my mind, is all about *which* settings
will
be used to auto-start the server, isn't it? an explicit command line, as
in "classic", should *always* take precedence over the settings in any
internal configuration database, which i think the "d-bus" honors
instead
and that latter behavior is being the root of all "d-bus" evil. scnrt ;)
cheers
--
My feeling is that is we choose the runtime auto-start strategy, then
we should not mix anything concerting setting management. Each
"incarnation" of server has it's own view of setting management and
this has to stay completely separated from any other view. If the used
chose "classic" auto-start strategy (that would stay the default yes)
then he is supposed to know that he has to use "classic" control tools
(Qjackctl..). If the user chose "D-Bus" auto-start strategy, then he
knows he has to use D-Bus aware control tools only and so on...
(there are two 5)'s above but i'll refer to the first one)
i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of
honoring .jackdrc if it exists on your home directory. ie. if .jackdrc
exists then do the "classic" auto-start; if not, check d-bus service;
etc.
byee --
rncbc aka Rui Nuno Capela rncbc(a)rncbc.org
But since some applications like Qjackctl or Ardour write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
9:26 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 11:37 +0100, Rui Nuno Capela wrote:
the main question, at least in my mind, is all about
*which* settings will
be used to auto-start the server, isn't it? an explicit command line, as
in "classic", should *always* take precedence over the settings in any
internal configuration database, which i think the "d-bus" honors instead
and that latter behavior is being the root of all "d-bus" evil. scnrt ;)
If jackdbus migrated the settings from .jackdrc the first time it is run
that would probably save a lot of hassle.
Damon
9:52 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 19 May 2009 12:25:35 +0100
Damon Chaplin <damon(a)karuna.eclipse.co.uk> wrote:
On Tue, 2009-05-19 at 11:37 +0100, Rui Nuno Capela wrote:
Don't know if that would be sensible but so far the only way to tell
jackdbus what settings to use is by editing the xml file or using
laditools, which hardly anyone used so far and isn't included in any
distribution. ladi is, to my knowledge, the only thing that uses the
dbus interface so far.
Philipp
the main question, at least in my mind, is all
about *which*
settings will be used to auto-start the server, isn't it? an
explicit command line, as in "classic", should *always* take
precedence over the settings in any internal configuration
database, which i think the "d-bus" honors instead and that latter
behavior is being the root of all "d-bus" evil. scnrt ;)
If jackdbus migrated the settings from .jackdrc the first time it is
run that would probably save a lot of hassle.
Damon 
9:57 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
<hollunder(a)gmx.at> writes:
Don't know if that would be sensible but so far
the only way to tell
jackdbus what settings to use is by editing the xml file or using
laditools, which hardly anyone used so far and isn't included in any
distribution. ladi is, to my knowledge, the only thing that uses the
dbus interface so far.
No. manually editing the xml file is not good idea unless you are sure
that you will not override them accidentally through dbus
interface. jack2 compes with a tool, jack_control. You can change all
settings with it. laditools do use the dbus interface. lash also uses
it. patchage can use it. lpatchage uses it always.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:03 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 11:32 +0200, Stéphane Letz wrote:
But since some applications like Qjackctl or Ardour
write this
".jackdrc" file in a possible hidden way for the average user, then
the system possibly goes back in the "classic" auto-start strategy,
without any knowledge of that.
a) very few jackd users are unaware of hidden .files
b) it works! what could possibly be wrong with that?
/j
7:47 a.m.
New subject: [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz <letz(a)grame.fr> wrote:
4) A possible proposed solution was to define 2
completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....). The problem of this strategy is that..., it is a kind
of complete failure regarding the way jack is supposed to be
distributed. It may even get worse if a new "jackosc" incarnation (a
one that would allow to control the server using OSC) appears a some
point in the future...
And we will all agree that this would be a packaging disaster. I package
jack for gentoo pro-audio, and I really don't know how I'd handle this one.
5) Another idea would be improve the "choice of
auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once
globally for a
given working session...
To me, this one is the cleanest of all, and would allow to keep auto-start
for those who like it with the flavor of their choice (and eventually
disable it for those who don't ?)
5) Another idea would be be to completely drops the
"auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Last resort but if it comes down to this, I can handle my idea of
auto-start directly inside LADITools using dbus calls. although it wouldn't
be as good as the "any client can auto-start jack" paradigm.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
9:55 a.m.
On Tuesday 19 May 2009 04:38:24 Stéphane Letz wrote:
Hi All,
After hours of discussion on #jack IRC, it seems that we are in a
completely blocked situation:
1) we currently have 2 "incarnations" of the jack server named
"jackd"
and "jackdbus". "jackd" is the legacy "classic" version of
the server
that interact with the ~/jackdrc setting file. This setting file may
be written by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware
version of the server, it use a completely new setting management
system using a "conf.xml" file. Il may use a multi-setting system in
the future.
So, when the classic jackd is running and you do a ps ax | grep jack what do
you see?
And when the new jackdbus is running and you do a ps ax | grep jack what do
you see?
2) the *heart" of the problem Fons initially told about is in the way
applications "auto-start" the server. This launching strategy is part
of libjack and depends of the incarnation of the server (jackd of
jackdbus) that is supposed to be used. Right now this strategy is
chosen at *compile time*, so that in "classic" mode the "jackd"
server
will be launched using a fork-exec strategy, or in D-Bus mode the
"jackdbus" server will be launched by issuing a D-Bus call.
3) Since the "auto-start" strategy is chosen at compile time
I don't think anyone has yet stipulated that this must be a compile time
option and not a run time config file option. Must it be a compile time
option?
and thus
is coded in libjack, users will typically encounter all sort of
problems as soon as the used applications interact with a "D-Bus based
strategy" libjack (that will launch "jackdbus" incarnation) and users
still use Qjackctl that interact with the "jackd" incarnation.
What would happen if the jackdbus incarnation checked for an rc file on launch
and, if it found one, rewrote its own xml file to match before proceeding
with startup. Then on each change of its own xml file, it could rewrite the
rc file. Would that give a quick and dirty fix to this issue until a better
solution is found?
4) Different ideas have been proposed to merge the 2 "jackd" and
"jackdbus" incarnations in a unique extended "jackd" exe, but
nothing
really clear emerged.
4) A possible proposed solution was to define 2 completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....). The problem of this strategy is that..., it is a kind
of complete failure regarding the way jack is supposed to be
distributed. It may even get worse if a new "jackosc" incarnation (a
one that would allow to control the server using OSC) appears a some
point in the future...
5) Another idea would be improve the "choice of auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once
globally for a
given working session...
What are the problems with this idea? For packages made by one person and
installed by others, aren't runtime choices better and more flexible than
compile time choices? (Generally...)
5) Another idea would be be to completely drops the "auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Comments?
I think we may not have paid enough attention to what others have been saying
in this thread. Myself included. And perhaps this has *"extended"* the
discussion.
Stephane
all the best,
drew
11:44 a.m.
On Tuesday, 19 May 2009 at 10:38, Stéphane Letz wrote:
4) A possible proposed solution was to define 2
completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....).
Wouldn't a dbus-based control application jackd work? I.e. a wrapper around the
dbus jack that behaves like the old jackd? (It seems like the obvious solution
to me, but I haven't read that much of this discussion, just part of what was
on this list, so if this is the stupid kind of obvious, just ignore me.)
5619
days inactive
5619
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
10 participants
participants (10)
-
Christian Ohm -
Damon Chaplin -
drew Roberts -
hollunder＠gmx.at -
Jens M Andreasen -
MarcO'Chapeau -
Nedko Arnaudov -
Patrick Shirkey -
Rui Nuno Capela -
Stéphane Letz