Expanded example with some more audio paths, and also that I added "$" for "$RANDOM" just for symmetry (although it shouldn't be needed) and removed the braces for $PICK (also not needed).

#!/bin/bash
AUDIO=( 
    $HOME/folder*/*.{wav,mp3,ogg}
    $HOME/with/some/path/*.mp3
    /usr/share/sounds/alsa/*.wav
)
LENGTH=${#AUDIO[@]}
PICK=$(( $RANDOM % $LENGTH ))
play ${AUDIO[$PICK]}

In detail,

• the AUDIO assignment is the collection of possible audio files, which in this example includes any files with extensions wav, mp3 or ogg in any home folder whose name starts with "folder", plus any mp3 file in the folder path "with/some/path" from the home folder, plus any wav file in (system) folder "/usr/share/sounds/alsa/";

• the LENGTH assignment is the number of pathnames in the AUDIO list;

• the PICK assignment is an integer between 0 and LENGTH-1 picked from a uniform distribution between 0 and 32767, modulo the length (which makes it favour lower numbers); and

• the play command is of the PICK:th pathname of AUDIO list

I'm sure you can edit the audio paths to suit your needs.

But, there's something funny going on if it doesn't pick at random; perhaps a misspelling? But if you used Copy-and-Paste then that wouldn't be the case. The other option is that the audio selection doesn't find more than one file.. You might check that by inserting

echo ${AUDIO[@]}

immediately after the assignment, and review that output....

There's a little bit of mismatch between:

and:

Perhaps it's worth to deal with that first, and then see if the problem remains.

That might be right; and the corresponding linux-headers would be at least in the server and desktop isos.
Though, the chimaera alpha ISOs are rebuilt every Monday and might now hold only the 5.10.0-7 package(s).

You find linux-image-5.10.0-0 in beowulf-backports. That's kernel version 5.10.24 (as opposed to 5.10.40 that is packaged as linux-image-5.10.0-7 and kernel version 5.10.28 that was packaged into linux-image-5.10.0-6)

Links for direct download of the .deb(s) could be:
linux-image-5.10.0-0.bpo.5-amd64=5.10.24-1~bpo10+1
and
linux-headers-5.10.0-0.bpo.5-amd64=5.10.24-1~bpo10+1

Yes it appears to be fully chromium's problem... are you sure it runs with your credentials rather than some "sandbox user" ?

You might try running

fuser -v /dev/snd/*

to see which if any (other) process "owns" the device.

Based on a shallow look-around, it would seem you'll need to get the "st" module loaded.

Perhaps a plain

# modprobe st

is sufficient, or maybe it needs some more intricate incantation.

(Possibly it needs a tape loaded at the time)

Look up Documentation/scsi/st.rst in the kernel source for details of that module.

I would call it Way Too Many.

tomoyo-tools seems to be to be upstreamed from http://tomoyo.osdn.jp/ (and why that is enabled in debian's standard linux-image is unkown to me). Apparently adding security=none to the boot command should disable this one.

Don't the instructions at https://wiki.winehq.org/Debian work for you?

I suppose, for a 64-bit Devuan beowulf, you will also need the prior

# dpkg --add-architecture i386

so as to enable "multiarch support".

Thereafter it's the usual 3 steps: download and add their key, add their "buster" repository sources.list point and update, and then install their package(s). (Though contrary to those instructions, I would always use --no-install-recommends for installing)

@dice's advice is for registering the connection details for the particular ESSID and WPAKEY.

For a laptop, you might want a slightly more flexible configuration, and to use the wpa_gui to deal with new wireless access points.

First, enter the following at the top of /etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
p2p_disabled=1

Secondly, bring down wlan0 (ifdown wlan0) before changing /etc/network/interfaces to have the follwing variant declaration:

auto wlan0
iface wlan0 inet manual
         wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

You'll note the difference of having a manual stanza with wpa-roam rather than wpa-conf, and a seemingly extra stanza declaring use of a dhcp configuration for a virtual default interface. All that is in support of roaming with dhcp.

Next, install wpagui (that's the package name for the wpa_gui tool) as user management tool for connecting your wireless interface to available acccess point by choice. By virtue of the update_config=1 setting you may save accesspoint settings so wpa_supplicant can find them "automatically" later.

You might also need to re-login the user after ensuring the user is in the netdev group, as per that first configuration line which wpa_supplicant will use for its control sockets.

With that you should be all set. for completeness, the p2p_disabled=1 is needed in order to disable that function which otherwise causes wpa_supplicant to be confused.. I'm not sure about the details.

Firstly, you cannot easily have two interfaces configured for the same network. I.e., if you want eth0 down and wlan0 up, you'd need to do that, in that order:

# ifdown eth0 ; ifup wlan0

Secondly, the gateway for static configuration does the same as your post-up additions to the wlan0 confguration; i.e. remove the post-up lines.

Thirdly, with allow-hotplug rather than auto you declare that networking should be managed via hotplugging, in which case udev will try to configure the nominated interfaces. Both of them if there is a cable, and potentially with a bit of race between them; one first, then the other. Since you have gateway declarations for both configurations, there will be a competition where the first one wins.

Possibly your misapprehension is that you regard the configurations as alternatives while udev will treat them as "complementary" or "conjunctive" and apply them both. Afaict the network management via either allow-hotplug (/lib/udev/net.agent) or auto (/etc/init.d/networking) don't actually detect "presence of cable" to only apply configurations "as per available cabling". Instead it will configure all interfaces that it is set to configure, i.e., both eth0 and wlan0, including the possible race and competition about gateway (aka default route).

The problem with 2 interfaces on the same network is that return traffic will go through the first unless you in addition set up a source based routing rule, so that the kernel has different routing tables for outbound packets depending on what the source IP is. That can be done, but it's not an automatic function in the kernel's networking logic.

... well spotted, thanks.