[LAU] Switch backend when Netjack Master becomes unavailable

[Len Ovens]

On Sun, 12 Jul 2020, Christoph Kuhr wrote:

I will answer both questions in one with my non-extensive answer.
> 
> I want the RPi4 to shut down when the USB connection is lost.

I expect Linux is pretty standard even on the RPi... if you are running 
dbus... at least the system dbus which may well run even on a headless 
system, then there is a dbus signal that can be monitored using a userland 
python script:

system_bus.add_signal_receiver(msg_cb_removed,
                dbus_interface='org.freedesktop.systemd1.Manager',
                signal_name='UnitRemoved')

in the call back (msg_cb_removed above) which will be defined something 
like:
def msg_cb_removed(*args, **kwargs):

     if args[0].find("sound-card") >= 0:
         a_if = args[0].split("sound-card", 1)
         audio_if = a_if[1].split(".", 1)[0]

after this audio_if is the card number that was unplugged. The advantage 
of using dbus is that this is a callback meaning the is no constant 
polling to do. However, I have found that you do then have to check if the 
device has actually gone away because this signal also shows up on an alsa 
reset.

this is done by checking for the presence of /proc/asound/card${audio_if}. 
Now this is what you would do in the polling method anyway with a loop:
while 1:
check for file
sleep 10
done

if you are doing the polling method, you may want to poll for 
/proc/asound/$cardname which is a symbolic link to the card$number 
directory in the same place.

> and another one...
> 
> Can I switch the backend to alsa without restarting jack, when the netjack
> master is lost?

depends and I would say not reliably. If you are using jackd, no. If you 
are using jackdbus yes. Use jack_control to change all the settings like 
back end then send another jack_control with sm (switch master). With 
jackdbus you can change the settings while it is running and they will 
have no effect until you send the switch master message. I have found that 
with some device combinations, sm just works and with others it works once 
and then the next time jackdbus locks up and requires a kill -9 to stop 
it. So if it happens to like you particular combination of devices (you 
might choose dummy as one of them so you can keep the same number of ports 
exactly) great. even if it works some of the time that is better than not.

However, having jack stop while running Mixbus should not be something 
that requires restarting anyway. in the menu Windows->audio/midi setup you 
should be able to reconnect to jack after restarting it. So even if 
running jackd and restarting it, just reconnect and continue.

reliably: with some device combinations (M66 PCI 12/10 i/o and USB 2/2 
i/o) I seemed to be able to switch to the USB device when plugged in but 
never back. with other combinations it seemed to work through 10 or more 
switches and then randomly stop working. The funny thing is that after 
switching through a combination that works well, I could switch through a 
combination that normally doesn't work well and it would now work fine. 
very hard to trouble shoot.

> I am running Mixbus on a netjack slave with an USB card connected to the
> netjack master. I do not want to restart the DAW when the master shuts down,
> but switch to the local alsa backend.

I have never tried sm with netjack and in this case the device detection 
is on another machine it seems. Try it and see.

jack_control/jackdbus and documentation... there is almost none and I 
found all I could by accident. Run jack_control with no 
parameters/arguments... -h or --help does not work and man jack_control 
did not either for me. man jackd in the debian distros is not accurate 
(example portmax defaults to 2048 man page says 256). So with jack_control 
run with no parameters to get a list of commands and the use those 
commands to get a list of parameters with their default:current values.

Also remember that most of the stuff you can find on the web is out of 
date... jack has been around since audio applications were run on machines 
with 1/4Gb Ram (hence port max 256) and really old kernels like 2.6. Even 
things that have been written in the past 5 years are often based on 
wisdom from many years prior. experimentation is really the only way 
forward.

--
Len Ovens
www.ovenwerks.net