jackd autostarts when jack application starts?

[grammo]

Odd. On Debian, since when does jackd autostart when you launch a application with jack support? This is unwanted, how do I turn it off?

It happens only when running non-session-manager it seems and applications like mamba and qmidiarp. Strange.

When a empty session is running with NSM_URL in environment. Mamba starts jackdmp

$ mamba
NSM: Successfully registered. NSM says: Well hello, stranger. Welcome to the party.Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jackdmp 1.9.19
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:CODEC|hw:CODEC|256|3|48000|0|0|nomon|swmeter|soft-mode|32bit
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback
Samplerate 48000Hz
Buffersize is 256 samples
jack running with realtime priority

[tramp]

This is normal and have nothing to do with NSM.
Jack aware applications needs a running jack server to start. If they can't connect to a running jack server, they try to start one. If that fail, the app simply didn't start.

[grammo]

Thx for your reply. Ok, so the particular application is doing this? Not jack itself.

Why don't they just fail loud? Carla gives an error for instance.

I think as a user, it's the task of the user to start Jack and that Jack applications should just fail at start when Jack is not running. I think that's also more in line with the Unix tradition. Don't try to be smart.

It really surprises me that even modular tools like non-sequencer do this. What should the application start, jackd or pipewire. I mean, this kind of 'smart behavior' should be avoided on Linux, in the long run it gives all kind of unwanted surprises.

[tramp]

It's a matter of taste.
When you start mamba, for example, it's pretty clear that you want to make some music. So when no jack server is running it starts one and you could start playing. I didn't see a issue with that, not even in any 'Unix tradition' . You could, start qjackctl as well afterwards to control the jack server or make some connections.
Or, to avoid that all, just start the jack server before you start any jack aware application.

[grammo]

No, it's not a matter of taste I think. It's a matter of technical design. It's easier to track down and avoid bugs or issues, when the procedure is simple and clear. I mean, it's not a task of a application to start a sound server. Now one application is autostarting jackd, the other not. That's extra complexity, which makes it hard to trace down issues. Moreover, the application does something I don't want.

My issue is exemplary, I see suddenly jackd being started and I've no idea how and why. So my initial thought, was maybe Pulseaudio does some autospawn thing or so. Maybe the new pipewire. I had to jump onto a forum board to find out how this happened.

This is not a matter of taste but about the design. When a lot of developers work on the same system, you better keep it simple and clear. That's also the lesson of Unix.

Edit: But that this is bad design becomes apparent right away:

I start mamba in a terminal.
Mamba starts jackd in the same terminal
I close mamba in the terminal
It also closes jackd.
Troubles is what you get.

[tramp]

You didn't understand how this works.

I start mamba in a terminal.
Mamba starts jackd in the same terminal
I close mamba in the terminal
It also closes jackd.
Troubles is what you get.

Yes, jackd quits when you quit mamba, but only when no other jack aware application is running. Just insert a step were you start qjackctl (or any other jack aware app, and jack will keep running, you could also close the terminal and jack will keep running, as long there is a client using it.
So the trouble you see, is only theoretical. In practise there is no issue.

[tramp]

. . . but, you could avoid jack auto start by application at all by but

Code: Select all

 export JACK_NO_START_SERVER=1

in your ~./bashrc

[grammo]

. . . but, you could avoid jack auto start by application at all by but

Code: Select all

 export JACK_NO_START_SERVER=1

in your ~./bashrc

Ok, that's nice.

edit:
$ mamba
NSM: Successfully registered. NSM says: Well hello, stranger. Welcome to the party.Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
jack server not running?
$

Mamba fails, while non-sequencer just starts, even when jackd is not running. Given the fact that non-sequencer works only with jackd AFAIK, you would think, it should fail to start here too. Non-Timeline doesn't start though. Hmm

But I don't think this problem is only theoretical. If you make your applications do all kind of smart things, you'll hit a situation when that smart thing is not what the user wants, or makes it hard to track down issues.

Again, I needed to jump and spend time onto a forum board to track down this issue. If the application just failed early and loud the solution was simple: Shoot I forgot to start jack first! Stupid me!

[tramp]

But I don't think this problem is only theoretical. If you make your applications do all kind of smart things, you'll hit a situation when that smart thing is not what the user wants, or makes it hard to track down issues.

Again, it seems you don't understand how that all work. And, you make a huge problem out of it.
Mamba don't do anything smart at all, it just try to connect to the jack server. It does this with the

Code: Select all

JackNullOption

set, which is the default for the jack server. How the jack server react on this call is leave to the jack server. Nothing that smart as you guessed.
https://jackaudio.org/api/types_8h.html ... 6f408a375e
And by setting a default fag in your ~./bashrc for it, you are the one who decide how the jack server react.

Again, I needed to jump and spend time onto a forum board to track down this issue.

It's always good to know the tools you work with.

Mamba fails, while non-sequencer just starts

Well, it may be that it starts, even guitarix could stay alive without a running jack server, but, it surely didn't work, and so, I guess also the non-sequencer wouldn't work. Now, you've to figure out why it didn't work.

It may be that for you it is annoying, that the jack server starts when a app try to connect to it, but, for others that may easier there life., and you, now have a way to set it up the way you prefer.

[grammo]

Mamba don't do anything smart at all, it just try to connect to the jack server. It does this with the

Code: Select all

JackNullOption

set, which is the default for the jack server. How the jack server react on this call is leave to the jack server. Nothing that smart as you guessed.
https://jackaudio.org/api/types_8h.html ... 6f408a375e

That's interesting info, thx.
So, it's not Mamba being 'smart' but jack?
Has this always been the behavior of jack, also in jack1?
Like I said, it surprises me a bit.

There seems to be a option to explicitly don't start jack too though, if I'm right:

Code: Select all

JackNoStartServer 	

Do not automatically start the JACK server when it is not already running. This option is always selected if $JACK_NO_START_SERVER is defined in the calling process environment. 

[tramp]

Has this always been the behavior of jack, also in jack1?

This was implemented on 20 Apr 2004, so not always, but since a long time already.

There seems to be a option to explicitly don't start jack too though, if I'm right:

Yes, and that is exactly what you could set in your environment to decide how you would like to handle the auto-start feature if the apps don't do it like you wish.

[grammo]

Is there also such env variable to disable autoconnect?

The manpage says there is a --autoconnect option, only what's the difference between ignore and fail?

-a, --autoconnect modechar
Select how to handle self connect requests. They can
be ignore or fail, on all port or just external ones.
Use the --help option to know your system specific
options. The default is to not restrict self connect
requests.

I would prefer a env variable though.