> > On Sun, 2020-03-29 at 11:35 +0200, Fons Adriaensen wrote: > > This *should* work of course, but I'm wondering why things are > > donethat 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 > > nexttrack ? > > 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 renderthread that > > > are not intended for use in that thread. > > > > Which ones are you calling there ? Normally there is no needat all > > to call Jack from the its own process() callback. > > > All jack client client call backs are handles througha message > > > queue, > > > > Except for process() I hope. Which other callbacks are youusing ? > > 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 anddisconnections > > > 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- > > > servershutdown 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 anyreason (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 tendsto run clients out of order, which depending on the > > application maygo unnoticed, or be a serious problem. > > Jack1 specifically doesn't provide glitch-less jack connection > changes, so that is not an option.
-Ethan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] https://lists.linuxaudio.org/listinfo/linux-audio-dev
