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(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org