I have embarked on a long journey of porting my radio automation and mixing system from OSX (making extensive use of Apple's CoreAudio API) to a Linux/JACK/gstreamer system and potentially, making it a cross platform application. The application is actually a collection of programs, ranging from a studio UI, library management UI, database back-end, and an faceless audio-engine/mix system. I am currently working on the audio-engine port, since potentially I could port that and continue to use the old UIs on Macs until I can get those ported as well.

In order to make this manageable, I decided to pull some audio features out of my existing audio-engine, notably AudioUnit effects hosting, IAX phone support, and multiple audio-device support. I should be able to add VL2 effects hosting and IAX back in at some point. But for the short term, I can use jack to host effects in another program for now, and just give up IAX/asterisk integration. The multiple audio-device support, via my own clock drift measurement and re-sampling scheme, is a loss for now, but it looks like alas-in and alas-out programs could be stop-gap approaches to that, and appears to use a similar underlying approach.

So far, the porting is going much faster than I had expected. Jack2 is a very clean and well though out API. It is not unlike CoreAudio, only it's MUCH easier to use. Leveraging JACKs inter-application audio routing, I have further broken my audio-engine down into a mixing system and control session host, with separate programs executed for playing and recording/streaming audio content. This a very nice, clean way to break thing up, made possible by JACK. Thanks.

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?

2) Again, with the named server: I can start a named jackd server. I can connect to it using QjackCtl by setting the name property in the advanced tab of QjackCtl settings. But when I try to connect to the named server from my audio-engine application, via a jack_client_open() call, passing the name char string, my application instead tries to start up a jackd server instance, using the command noted in the jackd man page (first line of $HOME/.jackdrc). Is this a bug, or am I missing some detail?

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?

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. 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?

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.