On Sat, Mar 28, 2020 at 12:38:46PM -0700, Ethan Funk wrote: > I have been working slowly on a port of a radio automation system I > originally wrote for OSX to a more general, cross-platform design using > jack-audio and gstreamer instead of Apple's Core audio API. As part of > the design change, I have separated the mix-engine and media handling > into separate processes, where the mixer forks media players, which > connect back the core mixer via jack, then are disconnected by the > mixer when finished, prior to the media player instance shutting down.
This *should* work of course, but I'm wondering why things are done that 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 next track ? The simple alternative is to have a fixed number of players running all the time, and just outputting silence when not playing a track. Whenever you need to play a track, find and idle player and use it. But as said, your approach should just work. I'm not yet convinced this is a Jack problem. I've had much more complex systems (with tens of jack clients coming and going and hundreds of ports) running for months. > I am not calling jack calls in the real-time render > thread that are not intended for use in that thread. Which ones are you calling there ? Normally there is no need at all to call Jack from the its own process() callback. > All jack client client call backs are handles through > a message queue, Except for process() I hope. Which other callbacks are you using ? > So it really does appear to be the connections and > disconnections 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-server > shutdown 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 any reason (e.g. connect or disconnect), or just by itself ? > Cannot read socket fd = 7 err = Success > CheckRes error > JackSocketClientChannel read fail > SuspendRefNum error > JackClient::Execute error name = ars9550 > Server is not running I'm not familiar with the Jack2 code, so I've no idea what that could mean. > I would like to run jackd in gdb so I can see where it is failing, but > I am unsure how to build it without breaking my system's installed jack > package, which is of course built without debugging enabled. You could also try Jack1 instead. Note that this has its own problems, in particular when connections are changing all the time -- it tends to run clients out of order, which depending on the application may go unnoticed, or be a serious problem. > Any help would be appreciated. Sorry, I can't help more... -- FA > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > https://lists.linuxaudio.org/listinfo/linux-audio-dev _______________________________________________ Linux-audio-dev mailing list [email protected] https://lists.linuxaudio.org/listinfo/linux-audio-dev
