On Sun, 2020-03-29 at 11:35 +0200, Fons Adriaensen wrote:

This *should* work of course, but I'm wondering why things are done

that way. In a 'real' studio, would you disconnect and remove e.g.

a CD player after each track, and install a new one for the next

track ?

In a real studio of old, mixers had 16, 32, and some times more stereo inputs, with a dedicated input for each of your 3 cart machines, 3 CD players, 2 turn tables, 4 microphones, two or more phone callers, 2 network feeds, RPU remote, a tape deck, and so on.  Huge mixers, with just a few channels used at a time.  Why so many channels?  Because DJs are not technicians, and can't be trusted to be allowed to change the mixer input configuration, even though they are only using a few channels at a time, some time just two channels as they segue between songs.

With a computer replacing the mixer entirely, I still have all sorts of audio sources:  some live like microphones and turn tables, some virtual like audio file players, network streams, and SIP phone sources.  And additionally sources like a jack source coming out of some other program.  Keeping the media handling as separate programs allows the core-mixer to have a relative small number of inputs, 8 by default.  Extra live inputs associated with physical audio device inputs and be added when needed, then unloaded when done. Use 1 live guest mic, or three if needed. Sources are treated as an abstrcation, allowing all different types of sources to be used now, and ones not thought of now, in the future. As long as you never need more than 8 sources running at once, your good.   Pre-loading takes you back to needing a lot of inputs for every possible source you could ever use, most of which are used only occasionally.

I am not calling jack calls in the real-time render

thread that are not intended for use in that thread.

Which ones are you calling there ? Normally there is no need

at all to call Jack from the its own process() callback.

All jack client client call backs are handles through

a message queue,

Except for process() I hope. Which other callbacks are you

using ?

For sure. My process call back is it's own direct callback function. It calls jack functions that a typical process function is expected to call:

jack_port_get_buffer

jack_midi_get_event_count

jack_midi_event_reserve

jack_midi_event_get

and the whole family of jack_ringbuffer functions. All are design to be used from the process function, as I understand it. Am I wrong?

I also call pthread_cond_broadcast some times from with in the process function, when it has done something that I want another thread in my program to go take note of. This seems like a typical and intended use of pthread_cond_broadcast, so I don't think that should be a problem.

All other jack calls are made in other program threads, and are made thread safe by wrapping  a dedicated mutex around jack function calls. I looked at the jack client source code back when I was having thread problems, and determined that none of the jack client calls I looked at were thread safe without a mutex lock. So rather than looking any deeper, I just put a lock around all calls.

So it really does appear to be the connections and

disconnections that are causing the trouble.

Yes.

Here is what I get from my arServer4 core-mixer program's stderr

(registered to jackd as "ars9550"), just before the jack-server

shutdown call back fires off:

What happens just before that, that would trigger a crash ?

In other words, does this happen when you call Jack for any

reason (e.g. connect or disconnect), or just by itself ?

jackd always crashes just short of one minute after a media player instance finished and has unregistered with jackd. Not the disconnection even, but the unregister prior to shutdown event. The 1 minute is a clue, but I don't know why jackd wait 1 minute to die.

You could also try Jack1 instead. Note that this has its own problems,

in particular when connections are changing all the time -- it tends

to run clients out of order, which depending on the application may

go unnoticed, or be a serious problem.

Jack1 specifically doesn't provide glitch-less jack connection changes, so that is not an option.