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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ethan Funk
Hello all.

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.

That is the big picture. I have come across some questions that I need a little help with, all regarding the start-up process of the jackd server:

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.

Thanks,
Ethan Funk


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

Jörn Nettingsmeier-5
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

Thomas Brand
In reply to this post by Ethan Funk
On Fri, March 8, 2019 19:12, Ethan Funk wrote:
> Hello all.
>

Some notes taken from jackd manpage that cover a few of the topics in your
mail here:

Every JACK client reads environment variables under the hood that can
control some of the aspects you refer to.

$JACK_DEFAULT_SERVER specifies the default server name.
As an example:
JACKD_DEFAULT_SERVER=nondefault jack_lsp

jack_lsp doesn't need special code for handling for that.

$JACK_NO_START_SERVER specifies to not start a server when none is running
(with given name).
As Nettingsmeier pointed out, you really want to start the server
separately with defined parameters and not rely on a client to do it.

Clients can control server name and autostartup behavior in code
explicitly by passing jack_options_t to the jack_client_open() function.

$JACK_PROMISCUOUS_SERVER allows for relaxed permissions, "allowing clients
from different users to talk with the same server"

Finally you can always wrap the server or client startups in a script or
have a small daemon that will do it iff the other approaches aren't good
enough.

Greetings
Thomas


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

David Nielson-2
On Sat, 2019-03-09 at 15:12 +0100, Thomas Brand wrote:
>
> Finally you can always wrap the server or client startups in a script or
> have a small daemon that will do it iff the other approaches aren't good
> enough.
>

For those who have done this, could you publish your configurations and how you got there?

Thanks,
David

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

Ethan Funk
In reply to this post by Thomas Brand
Thanks Thomas.

Needing to set the JackServerName option bit flag for jack_client_open() when passing a server name into the function is what I was missing when trying to connect to a named jackd server. And along that same line, the JackNoStartServer flag also solves my server auto-start problem from my client. It's good to know that the environmental variables referenced in the jackd man-page are also used by the client API. That wasn't apparent to me.

Thanks... you save me a lot of time looking through the jack source code!

Ethan...

On Sat, 2019-03-09 at 15:12 +0100, Thomas Brand wrote:
On Fri, March 8, 2019 19:12, Ethan Funk wrote:
Hello all.


Some notes taken from jackd manpage that cover a few of the topics in your
mail here:

Every JACK client reads environment variables under the hood that can
control some of the aspects you refer to.

$JACK_DEFAULT_SERVER specifies the default server name.
As an example:
JACKD_DEFAULT_SERVER=nondefault jack_lsp

jack_lsp doesn't need special code for handling for that.

$JACK_NO_START_SERVER specifies to not start a server when none is running
(with given name).
As Nettingsmeier pointed out, you really want to start the server
separately with defined parameters and not rely on a client to do it.

Clients can control server name and autostartup behavior in code
explicitly by passing jack_options_t to the jack_client_open() function.

$JACK_PROMISCUOUS_SERVER allows for relaxed permissions, "allowing clients
from different users to talk with the same server"

Finally you can always wrap the server or client startups in a script or
have a small daemon that will do it iff the other approaches aren't good
enough.

Greetings
Thomas




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

Thomas Brand
In reply to this post by David Nielson-2
On Sat, March 9, 2019 18:26, David Nielson wrote:

> On Sat, 2019-03-09 at 15:12 +0100, Thomas Brand wrote:
>
>>
>> Finally you can always wrap the server or client startups in a script
>> or have a small daemon that will do it iff the other approaches aren't
>> good enough.
>>
>
> For those who have done this, could you publish your configurations and
> how you got there?
>

What is your usecase, where isn't it covered by "default" behavior?

Greetings
Thomas

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

David Nielson-2


On Sat, 2019-03-09 at 22:48 +0100, Thomas Brand wrote:
> >
> > For those who have done this, could you publish your configurations and
> > how you got there?
> >
>
> What is your usecase, where isn't it covered by "default" behavior?
>

Currently I have one host with two soundcards (on the motherboard + RME RayDAT) where the
SPDIF output on the motherboard goes into the RME card, providing signal plus sync.
PulseAudio only knows about the on-board audio, and JACK only knows about the RME card. So
my family (who aren't sysadmins) can play Netflix and Youtube, and adjust some faders to
make it play in different parts of the house. They don't have to think about the LV2
plugins providing an active crossover for the main sound system. :-)

Honestly I'm not sure what default means anymore; I've been doing this for so long and have
grown so accustomed to compiling everything from source. I've documented some of my setup
but I have no idea if it would actually help anyone else. It's not my best work.

https://wiki.naptastic.com/nndocs/lad

Please do feel free to email me directly with "ZOMFG YOU'RE DOING IT WRONG". This
configuration is starting to smell funny.

Eventually I intend to have a computer in every room with an audio interface attached, and
transport all audio over the network. The way my house is set up, I could theoretically
have three recording sessions going at the same time controlled from one room. I've got a
lot of work to do before I can even start on the networked audio part. My home network is a
dog's breakfast.

David

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: List of jackd startup and named instance questions

Jörn Nettingsmeier-5
In reply to this post by Thomas Brand
On 3/9/19 3:12 PM, Thomas Brand wrote:

> $JACK_PROMISCUOUS_SERVER allows for relaxed permissions, "allowing clients
> from different users to talk with the same server"

Oh wow, I did not know that one. Thanks! It seems it even works in a
sane way, using group permissions rather than making everything
world-readable..

--
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Callback question on mutex/blocking

Ethan Funk
In reply to this post by Ethan Funk
Regarding call back registration:

jack_on_shutdown();
jack_set_client_registration_callback();

Am I correct in assuming that the call back functions will not be called from a real-time thread, and can safely block for short periods of time?

Thanks,
Ethan Funk


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (849 bytes) Download Attachment