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
