[LAD] Looking for some jackd debugging help

[Ethan Funk]

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20200329/760f0b8a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20200329/760f0b8a/attachment.sig>