Re: [LAD] Looking for some jackd debugging help

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. 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. 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. Jack1 specifically doesn't provide glitch-less jack connection changes, so that is not an option.