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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
