Re: [LAD] Looking for some jackd debugging help

From: Ethan Funk <ethan@email-addr-hidden>
Date: Sun Mar 29 2020 - 20:59:42 EEST

> > 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Received on Mon Mar 30 04:15:02 2020

This archive was generated by hypermail 2.1.8 : Mon Mar 30 2020 - 04:15:02 EEST