SSR should not auto-launch jackd

[umlaeute]

SSR should not auto-launch jackd

[umlaeute]

NOTE: I haven't actually tested whether ssr really launches jackd (as I have switched to pipewire on everyday work machines, and there jackd is virtually always running). just forwarding what i gathered in the other bugreport.

[mgeier]

AFAIK, the SSR uses the default behavior of the JACK library.

I guess we could implement an option to enable JackNoStartServer, see:

https://github.com/AudioProcessingFramework/apf/blob/0f5f6fad24dd6374a1cf4c01f0a5efaf9853a843/apf/jackclient.h#L495-L498

Is there a general recommendation or something to not use the default behavior?

But if jackd is started even though PipeWire is already running, doesn't this sound like a bug somewhere?

[umlaeute]

But if jackd is started even though PipeWire is already running, doesn't this sound like a bug somewhere?

no, not really.
pipewire can act as a JACK replacement, but it doesn't need to.
specifically, you have to explicitly either use pw-jack or setup your ld.so.conf (so the system uses pipewire's replacement libjack). if you haven't done so (and #340 (comment) makes it obvious that the poster there did not), then the two worlds do not mingle.
in my case (as opposed to the OP of #340), I have pipewire running in full jackd emulation mode, and therefore jackd is always running and ssr does not attempt to launch a jackd server on its own (that's why I wrote that "I haven't actually tested")

[umlaeute]

Is there a general recommendation or something to not use the default behavior?

so here's a transcript of a short conversation that took place on #jack on libera last night (I've slightly amended the text, merging multiple lines, fixing spelling mistakes, replacing names,...; i don't think i've changed the meaning of anything)

19:16 @umlaeute moin. i recently suggested to somebody that they should make sure that there jack client does not auto-start jack (so they should add JackNoStartServer), because "in the past this has led to all kinds of trouble (due to process-ownership and inheritance), and usually is considered bad practice." now they've asked me to backup this claim, and it seems i cannot come up with any references :-) so what would you suggest? should clients attempt to start jack-server if it is not running? or is this really deprecated behaviour (as i have claimed)? (iirc, the troubles usually showed when closing the application that started jackd and other apps where still attached to the daemon.) ftr the actual discussion takes place at #341 (so if somebody with an authoritative saying would chime in there, that would even be better than answering here :-)
19:23 @falkTX this ought to be obvious. if jack is not running yet, it is very unlikely it will be started up correctly. either

1. the user has setup jack before and thus knows how to do it again so this is not a big problem, or
2. user didn't set up anything yet and jack likely will fail to start.

with pulseaudio so common on desktop distros, the likelihood of jack being able to start with 0 user action is almost none. plus being started with the correct/wanted details, which is just guess work without user input
19:41 @umlaeute but the default is to start jackd (i presume: this is the default for historical reasons), and yet the header files document this option just as any other option. also, it is not really the concern of the authors of a jack client, whether jackd is smart enough to start up correctly without any configuration. (so i think it's valid for the authors to assume that the defaults are doing something sane)
19:48 @falkTX IMO we should make non-start the default; the landscape has changed from when jack was initially developed, alsa became quite complex. and with pipewire there is always a "jack" available
20:02 @umlaeute totally.

[mgeier]

I have created AudioProcessingFramework/apf#21 in the APF submodule, we can include that change in the next SSR release.

[mgeier]

This is now part of the master branch, and will soon be released.