Re: [LAD] should JACK programs autostart the server?

From: Rui Nuno Capela <rncbc@email-addr-hidden>
Date: Fri Sep 21 2018 - 10:39:01 EEST

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Sep 21 12:15:02 2018

This archive was generated by hypermail 2.1.8 : Fri Sep 21 2018 - 12:15:02 EEST