[Jack-Devel] Cannot callback the server in notification thread!

[Ethan Funk]

Yes, what you describe is what I am implementing.  I have also called
it "persistence" in my application. Normally, when all audio ports are
disconnected, my application quits.  But I have an command line option
to keep it running and have it "persist," not quit, try to reconnect.
I just implemented a simple queue of jack_port_ids.  Callbacks add
their relevant port_ids into the queue, with my main thread checking
the queue periodically, to further check the queued ports for re-
connection.  This was not as hard as I though it would be, and works
well so far.  Just queueing the port id is a lot simpler that what you
are doing in MusE, but it is sufficient for my application.
One remaining question: Am I safe assuming that jack2 will call my
callbacks one at a time from a single thread, or do I need to make my
port id queue writing function thread safe, just in case jack2 calls my
callbacks concurrently?
Ethan...
On Fri, 2019-08-09 at 01:52 -0400, Tim wrote:
> On 8/8/19 10:20 PM, Ethan Funk wrote:
> > In an application I am writing, I am getting an error message out
> > stderr (see email subject), and a connection failure return result,
> > when I try to use jack_connect() from inside a
> > jack_set_port_registration_callback function, using Jack2. My goal
> > is to have the application remember and re-connect to a
> > disconnected port if/when it "comes back." Am I going to need to
> > create a mostly sleeping thread just for port re-connections
> > attempts, or is there something obvious I am missing?
> > Thanks,Ethan...
> 
> If I understand your goal, I did this in MusE.I called it 'persistent
> connections', or 'persistent ports'.
> For example you can unplug a USB midi device currently  in use by
> MusE as a 'Jack device', then re-plug it,  and MusE will
> automatically reconnect to its ports  as if nothing happened and you
> may continue playing.(I made our 'ALSA devices' do the same thing!)It
> should also work with other Jack clients.
> Look in our driver/jack.cpp, at:   static void
> registration_callback(...),   static void
> port_connect_callback(...),  and   static int
> graph_callback(...),   // This is called in the gui
> context,   //  triggered by graph_callback()   void
> JackAudioDevice::graphChanged().
> It was complicated. Very. I needed to support Jack 1 and 2.So there
> are a few sequences of calls and resulting  sequences of callbacks
> for example that are different  in Jack 1 and 2. Several tricks and
> traps. See comments.
> My system relies HEAVILY on the jack port 'alias names',  because it
> was pretty much the ONLY thing you can rely on,  because the regular
> port names and port numbers change  upon re-plugging. It
> automatically chooses which alias is  best or falls back to the not
> so good canonical port name.
> So, that's what it 'remembers' between device plug ins -  simply the
> port alias or name text.
> HTH.Tim._______________________________________________Jack-Devel
> mailing listJack-Devel at lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20190809/ff95dae1/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/jackaudio/attachments/20190809/ff95dae1/attachment.sig>