[Jack-Devel] List of jackd startup and named instance questions

[Jörn Nettingsmeier]

On 3/8/19 7:12 PM, Ethan Funk wrote:
> Hello all.
> 1) At first, JACK seems to be designed for a single jackd server running 
> on a system, with the server control API lacking, as far as I can tell, 
> a method to control multiple servers by name. But then, with the name 
> command line option, I can actually run multiple servers tied to 
> different audio devices. Does the server control API simple not support 
> names at this point? Maybe this is just how JACK evolved, originally one 
> jackd per machine, then named server support added, but not fully 
> implemented across all the API?

I think the root of the problem is that the people who came up with the 
idea of multiple named servers seem to really regret it. It's not 
supported consistently by clients, it will break things for any but 
really advanced users, and it creates a support problem in the 
community. I wouldn't necessarily rely on it. Most scenarios can be 
solved with a single server. And running separate graphs on one machine, 
possibly as different users, to create some sort of separation of 
concerns, is bound to fail - this being realtime jobs, each server can 
totally hose all the others if it misbehaves. I know this is the age of 
VMs, but here's a reason to really, really push a separate iron into 
your rack...

Data exchange between JACK servers on separate hosts is easy and 
reliable, if needed.

> 2) Again, with the named server: I can start a named jackd server. 

It's probably a bug. It's definitely God's way of telling you not to.

> 3) Regarding the jack_client_open() behavior when no server is yet 
> running: the function call does seem to execute the first line of 
>   $HOME/.jackdrc and start the jackd server running. However, it appears 
> to inherit all the file descriptors from my application. This is a 
> problem because my application is designed to self-restart on a crash. 
> With jackd holding my application's TCP control socket open, my 
> application can't restart (bind again to the desired TCP port) until 
> after I kill the jackd process. I assume the auto-jackd startup code is 
> forking and execing, and the code simply isn't closing the parent's file 
> descriptors. Is this a bug or intentional? Is there a way I can detect 
> if a jackd server is running ahead of time, so I can start the server 
> myself using my own fork/exec which would closing my descriptors on the 
> child, then, once I know jackd is running, call jack_client_open() in my 
> app?

First of all, as a pro user, I find apps auto-starting JACK extremely 
annoying.
The behaviour you describe sounds like a bug, but (just a guess) it 
might be because of the semaphore communication between JACK clients...

In a professional setting, don't auto-start JACK. Bring it up as a 
system service (so you get all of systemd's watchdog features), or if 
you must, tie it to a user's login session, although that's usually not 
the best way.

Then test for JACK when you start, and if it isn't there, fail. A user 
that is going to have a use for a radio automation system won't need 
this 2% usability improvement, but will dislike the 150% burden on 
debugging and tuning the system.

> 4) because my audio-engine is a faceless application, and can be run 
> without a desktop session, I need it to be able to connect to a jackd 
> server run by other users, or to start a jackd server that can be used 
> by other users.

AFAIK, that's not going to happen by default. Look at /dev/shm/jack-* - 
this is how libjack passes the baton from one client to the next.
There may be a way to make these world-readable (I recall people have 
tried this), but it's pretty much the single most un-unixy thing I can 
imagine.

> I can verify that with Ubuntu 18.10, I can not start 
> jackd from a user account, then connect to it from my application 
> running as a different user, even if I run my app as root, not that I 
> intend to do that as a real world workaround. Is there some approach, 
> group permissions possibly, to allowing other users to access a jackd 
> server?

As stated above, since there is no real compartmentalisation from one 
user to the next if they share a realtime graph, maybe it's not the best 
approach. Why not run all JACK jobs as one user, and provide user 
interfaces to several users if you must?

Then again, I will admit that I have no idea about a complex radio 
workflow, so my argument might be valid from a JACK perspective only.

But if it's as simple as having N people hosting N radio shows at the 
same time that will be handled by a single playout server: give each of 
them a playout machine with all relevant functionality and a sound card 
for local monitoring and external equipment only. The program out goes 
to a network feed. I recommend zita-njbridge. It will totally isolate 
your clients from the central server, and even provide adaptive 
resampling if you have no way of synchronizing clocks. If you are in a 
studio facility with the necessary infrastructure, you can even hook 
everything up to the house wordclock and tell zita-njbridge to not 
bother resampling, in which case it will be bit-transparent.
I'm sure I haven't even scratched the surface of your workflow needs, 
but I hope it might give you ideas.

> 5) Wishful thinking: Give jackd the ability to read QjackCtl config 
> files, so I could configure things from the GUI, then stop jackd and be 
> able to restart it from the server-control API or command line with a 
> command line option pointing to a config file. Better yet, make a 
> persistent JACK-aware place to store such file in the file hierarchy.

Will that be worth the trouble? All the state of JACK that I need to 
know in my daily work is in .jackdrc.

If you find yourself needing to assemble a complex graph from several 
JACK clients that is nonetheless static, i.e. needs to be recreated in 
exactly the same way every boot, maybe consider hardcoding it into a set 
of systemd service files, with calls to "jack_connect" in ExecPost. Has 
the nice side effect that if a component dies, systemd will log it for 
you and restart it if you want.
Quoting from memory, it's better to solve the right problem badly than 
the wrong problem well :-D


Best,


Jörn




-- 
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net