21 Sep
2018
21 Sep
'18
11:39 a.m.
On 2018-09-21 06:46, bill-auger wrote:
On Thu, 20 Sep 2018 14:48:45 +0000 Rui wrote:
no. i wasn't implying anything. JACK_NO_START_SERVER should be honored
and i believe it is;
a. jackdbus *do* auto-start the jack-server if
not already running;
b. legacy jackd *do* auto-start exactly what's in "~/.jackdrc" file;
fwiw. i do have this "/absolute/path/to/qjackctl --start" in there,
so that qjackctl pops up whenever a(ny) jack client application is
called ;) (*)
both of the above scenarios are summoned as soon jack_client_open()
is called *without* the JackNoStartServer option set.
my.02eur
cheers
Rui - was that implying that those actions will happen even if
JACK_NO_START_SERVER=1 is set?
also, that is only to say what actually happens though
- you did not
actually give your opinion of whether the client should try to start
the server
i'm kinda neutral on that matter, sorry.
imho. though i'm happy with the jack auto-start feature, specially the
.jackdrc "hack" to start qjackctl instead of the jackd server directly:
it gives me all the visibility and control over the jack audio system
life cycle, on each of my desk- and laptops.
almost everyone has agreed that it should not - but
one additional
reason that i can add is that it is very much an inversion of the
classic "client/server" relationship - generally speaking, a client
never "causes" the server to do anything - in a proper
"client/server"
relationship, the client "requests" some action of the server, and the
server decides whether or not to fulfill that request - any deviation
to that is an unconventional convenience - when the server refuses the
request or does not respond, it is properly the client's responsibility
to alert the user that the server is either broken, or the server admin
does not permit that behavior - IMHO, if the user happens to also be
the admin, that is most typically co-incidental, and it means that
they,
as the admin, can and should learn how to configure and enable that
behavior explicitly - it seems to me that this "user-friendly" feature
is only replacing the un-experienced user's disappointment that: "the
JACK program wont start" with: "the JACK program started, but now my
media player has no sound"
also, FWIW strictly speaking, a request to "start yourself" is actually
nonsense - if it were not already running, it could not handle that or
any request - this is really more like a request to "activate yourself"
- that seems to be what Rui's reply was suggesting - that the clients
will request the server to start accepting connections but the server
will refuse if JACK_NO_START_SERVER=1 is set
no. if JACK_NO_START_SERVER=1 is set the jack-server won't get
(auto-)started and clients will fail to activate their jack driver
code--no ports registered, no connections possible anyway--for most jack
clients out there this is often a death sentence.
another reason, for completeness, that was probably
everyone took as
implicit, is that: if the server does start at the client's request,
and if the user has not edited ~/.jackdrc, then the server will have
the
extremely liberal default buffering and will result in a pretty
terrible
"real-time" looping experience - so, the very person that this
"user-friendly" option is catering to, will be the ones that conclude
"this program sucks"
yes.
i think what i should do is have it
'JackNoStartServer' by default, and
add a configure option to enable it - then, debian can enable it
without
a patch
i'm afraid it's too late for that going into the decade old stable
jack-API;
better resort to set JACK_NO_START_SERVER=1 on default users shell
profile.
cheers
--
rncbc aka. Rui Nuno Capela