<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Sun, 2020-03-29 at 11:35 +0200, Fons Adriaensen wrote:</div><pre>This *should* work of course, but I'm wondering why things are done</pre><pre>that way. In a 'real' studio, would you disconnect and remove e.g.</pre><pre>a CD player after each track, and install a new one for the next</pre><pre>track ?</pre></blockquote><pre><br></pre><pre><div style="font-family: "Nimbus Sans L"; font-size: 14.666666984558105px;">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.</div><div style="font-family: "Nimbus Sans L"; font-size: 14.666666984558105px;"><br></div><div style="font-family: "Nimbus Sans L"; font-size: 14.666666984558105px;">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.</div></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>I am not calling jack calls in the real-time render</pre><pre>thread that are not intended for use in that thread.</pre></blockquote><pre><br></pre><pre>Which ones are you calling there ? Normally there is no need</pre><pre>at all to call Jack from the its own process() callback.</pre></blockquote><div><br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>All jack client client call backs are handles through</pre><pre>a message queue,</pre></blockquote><pre><br></pre><pre>Except for process() I hope. Which other callbacks are you</pre><pre>using ?</pre></blockquote><div><br></div><div>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:</div><div>jack_port_get_buffer</div><div><br></div><div>jack_midi_get_event_count</div><div>jack_midi_event_reserve</div><div>jack_midi_event_get</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>So it really does appear to be the connections and</pre><pre>disconnections that are causing the trouble.</pre></blockquote><pre><br></pre><pre>Yes.</pre><pre> </pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Here is what I get from my arServer4 core-mixer program's stderr</pre><pre>(registered to jackd as "ars9550"), just before the jack-server</pre><pre>shutdown call back fires off:</pre></blockquote><pre><br></pre><pre>What happens just before that, that would trigger a crash ?</pre><pre>In other words, does this happen when you call Jack for any</pre><pre>reason (e.g. connect or disconnect), or just by itself ?</pre></blockquote><div><br></div><div>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.</div><pre> </pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>You could also try Jack1 instead. Note that this has its own problems,</pre><pre>in particular when connections are changing all the time -- it tends</pre><pre>to run clients out of order, which depending on the application may</pre><pre>go unnoticed, or be a serious problem.</pre></blockquote><pre><br></pre><div>Jack1 specifically doesn't provide glitch-less jack connection changes, so that is not an option.</div></blockquote><div><br></div><div>-Ethan</div></body></html>