[LAD] Looking for some jackd debugging help
ethan at redmountainradio.com
Sun Mar 29 19:59:42 CEST 2020
> > 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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the Linux-audio-dev