[LAD] should JACK programs autostart the server?

Rui Nuno Capela rncbc at rncbc.org
Fri Sep 21 09:39:01 CEST 2018


On 2018-09-21 06:46, bill-auger wrote:
> On Thu, 20 Sep 2018 14:48:45 +0000 Rui wrote:
>> 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?
> 

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

> 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


More information about the Linux-audio-dev mailing list