[LAD] should JACK programs autostart the server?

Discussion:

bill-auger

2018-09-20 03:30:31 UTC

the debian maintainer of freewheeling suggested that it should
autostart the server if it is not running (change JackNoStartServer to
JackNullOption)

i have my opinion; but i am interested in others

https://sources.debian.org/src/freewheeling/0.6.4-1/debian/patches/060_jackstart.diff/

Christopher Arndt

2018-09-20 03:36:50 UTC

Permalink

I personally hate that behaviour, because I'm alway running jack-dbus
and start and stop the server via a DBUS-client.

Thatswhy I always have

export JACK_NO_START_SERVER=1

in my ~./bashrc.

Chris

hgn

2018-09-20 15:11:24 UTC

Permalink

Post by Christopher Arndt
Thatswhy I always have
export JACK_NO_START_SERVER=1
in my ~./bashrc.
Chris

Is that always honored and one can rely on that setting?

Christopher Arndt

2018-09-20 18:06:54 UTC

Permalink

Post by hgn

Post by Christopher Arndt
export JACK_NO_START_SERVER=1

Is that always honored and one can rely on that setting?

Yes.

https://github.com/jackaudio/jack1/blob/cb654ada4ecfd6a95b9fb648ebd33c5af462d380/libjack/client.c#L1023

https://github.com/jackaudio/jack2/blob/cc8576a7ab62caab10c7ddd7309367cf797c5e69/posix/JackPosixServerLaunch.cpp#L229

Chris

Jacek Konieczny

2018-09-20 06:15:40 UTC

Permalink

I hate apps auto-starting Jack. Setting Jack right is a tricky task and
it is good to have proper way to monitor the daemon. That is why we have
front-ends like qjackctl or Cadence. With jack auto-started in the
background we loose much of the control and apps may become
unpredictable when they are sometimes started after qjackctl/Cadence and
sometimes before that. I prefer to see the warning message that Jack is
not running.

On the other hand, I can understand some may prefer more transparent
behavior, like it happens with PulseAudio.

Jacek

Fons Adriaensen

2018-09-20 12:02:15 UTC

Permalink

Definite NO.

People who suggest autostarting usually don't understand what
Jack is and how it is used.

Ciao,

--
FA

Rui Nuno Capela

2018-09-20 14:48:45 UTC

Permalink

Post by Fons Adriaensen

Definite NO.
People who suggest autostarting usually don't understand what
Jack is and how it is used.

may i add my 2-point not-so-extreme-stance-of-sorts?

there it goes:

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
--
rncbc aka. Rui Nuno Capela

(*) ps. i often test over recent jack2/jackdbus "enabled" distros (read
ubuntu, debian, whatever) and as a matter of fact the .jackdrc "hack"
seems to work there too; that is, qjackctl pops up whenever jack-server
is called in; even though it's configured to talk with jackdbus
service... advantages to that bizarre situation goes like the
jack/pulseaudio bridge becomes fully "automagic" then, as to a full
desktop UX ootb. ;)

bill-auger

2018-09-21 05:46:12 UTC

Permalink

Post by Rui Nuno Capela
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

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

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"

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

Rui Nuno Capela

2018-09-21 07:39:01 UTC

Permalink

Post by bill-auger

Rui - was that implying that those actions will happen even if
JACK_NO_START_SERVER=1 is set?

no. i wasn't implying anything. JACK_NO_START_SERVER should be honored
and i believe it is;

Post by bill-auger
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.

Post by bill-auger
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.

Post by bill-auger
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.

Post by bill-auger
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

bill-auger

2018-09-21 09:27:15 UTC

Permalink

Post by Rui Nuno Capela

Post by bill-auger
i think what i should do is have it 'JackNoStartServer' by default, and
add a configure option to enable it

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.

you may be misunderstanding my suggestion or my position in this - i am
not the debian maintainer - i have no control over the user skel and it
would be intrusive and pretentious to write to their .bashrc - i am the
upstream maintainer trying to satisfy both debian who wants clients to
autostart JACK, and also non-debian users who may take my binary
packages or compile themselves

i was suggesting to add a switch to the ./configure script of
freewheeling (not to JACK) such as: '--enable-jack-autostart', that
would select between two '#ifdef' blocks in the source code at
compile-time; one with 'JackNoStartServer' passed to jack_client_open()
and the other with 'JackNullOption' depending on whether or not
'--enable-jack-autostart' was given to ./configure - debian could use
that switch, debian users could over-ride that behavior with
JACK_NO_START_SERVER if they choose to, and others could choose for
themselves at compile-time; all without anyone patching

Len Ovens

2018-09-20 16:53:20 UTC

Permalink

In my opinion jack should never start itself. I spend more time on irc
helping people "killall -9 jackd jackdbus" than just about anything else.
It is a slick idea but in practice it causes more trouble than it's worth.

Setting up jack to be my audio device (starts at session start) has been
the least trouble.

While advertized as help for newbys, in the end this is an advanced option
only useful for those who understand jackd well... default off makes the
most sense.

--
Len Ovens
www.ovenwerks.net

Will Godfrey

2018-09-20 17:29:27 UTC

Permalink

On Thu, 20 Sep 2018 09:53:20 -0700 (PDT)

Post by Len Ovens

In my opinion jack should never start itself. I spend more time on irc
helping people "killall -9 jackd jackdbus" than just about anything else.
It is a slick idea but in practice it causes more trouble than it's worth.
Setting up jack to be my audio device (starts at session start) has been
the least trouble.
While advertized as help for newbys, in the end this is an advanced option
only useful for those who understand jackd well... default off makes the
most sense.

I'm against the idea of autostart as well. In my experience anything that does
that is a recipe for unintended consequences.

--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.

Nikita Zlobin

2018-09-20 18:28:55 UTC

Permalink

In Thu, 20 Sep 2018 03:30:31 +0000

Post by bill-auger
the debian maintainer of freewheeling suggested that it should
autostart the server if it is not running (change JackNoStartServer to
JackNullOption)
i have my opinion; but i am interested in others
https://sources.debian.org/src/freewheeling/0.6.4-1/debian/patches/060_jackstart.diff/
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

It's not a subject to be hated or must have, as depends on exact
situation. I made setup with desktop JACK setup, similar to kxstudio,
but different - pulseaudio constantly hangs runing with only jackdbus
module for audio devices, so when jackdbus needs to be shutdown, pulse
is over there, awaiting with nullsink for next jack run. But with
periodically runing jack - autostart would be handy, just to save a
couple of seconds, allowing to simply launch app, without worrying
about jack status.

Post by bill-auger
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 ;) (*)

Last time i tried to argue about libjack ability to use jack via dbus
if available, i was unaware about what ~/.jackdrc allowes - would be
strange, to open qjackctk settings and... write "/usr/bin/qjackctl" to
command line :)