Am 20.09.18 um 17:11 schrieb hgn: Yes. https://github.com/jackaudio/jack1/blob/cb654ada4ecfd6a95b9fb648ebd33c5af46… https://github.com/jackaudio/jack2/blob/cc8576a7ab62caab10c7ddd7309367cf797… Chris

On Thu, 20 Sep 2018 14:48:45 +0000 Rui wrote: 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

On Fri, 21 Sep 2018 07:39:01 +0000 Rui wrote: 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

On Thu, 20 Sep 2018 09:53:20 -0700 (PDT) Len Ovens <len(a)ovenwerks.net> wrote: 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.