Just for the wider audience: it' not a good idea to redefine the "hw" PCM. (If it works for you then you should keep it)

The most common way to set the default card is by an ~/.asoundrc or ~/.config/alsa/asoundrc with content

defaults.pcm.card 1
defaults.ctl.card 1

Of course, that applies for that user only. A system-wide setting would be to add the same in /etc/asound.conf (or any of the other places that ALSA configuration loader looks in).

You'd probably be better off playing on "plughw" rather than "hw" as it includes audio format translations.

But, when the card selection is done, the next is to look at the amixer settings.

The "problem" is that the machine has 2 cards and the ALSA default setup uses card 0 for playback.
The remedy is to change that to use card 1.
One way to do that (when there is a single user involved) is to make a file ~/.asoundrc that contains such reassignments, e.g.:

pcm.!default card 1
ctl.!default card 1

Note that the file allows comments as lines starting with '#'.

Read more about it at https://www.alsa-project.org/wiki/Asoundrc

EDIT: "pcm" refers to the audio channels (playback and recording) whereas "ctl" refers to "control knobs". ALSA is hugely configurable with an overly flexible configuration language and I believe anyone trying to delve into it very quickly enters into a state of deep confusion. Unfortunately.

The first "point of call" for packages could be like:
  https://pkginfo.devuan.org/systemd-boot
  https://pkginfo.devuan.org/systemd-boot-efi
Those packages are in the repo without forking since chimaera.

Fair enough; though that storyline that "systemd fixed something unsustainable for developers" is and was just plain marketing speech, and it's far off any reality. But the proponents sure filled the web with that thought so it's voiced failry commonly.

Yes Xorg has gone through a couple of steps through partially defunct versions. This originates in the sudden fork need when debian tied Xorg to systemd as way of supporting the use case of "non-root process owner without direct access to input device nodes". The solution was to interact over dbus with logind for mediating input access  and thereby draw Xorg into the systemd  web of entanglement.

The immediate fork remedy was to instead use libseat and offer the alternatives of using seatd as well as logind (over dbus) for input mediation, as well as including a "built-in" variant for system cases where the non-root user does have direct input access.. This forking task has taken a couple of iterations to stabilize. Supposedly it's now in good working condition.

A quick glance at https://pkginfo.devuan.org/libdvd-pkg tells us that the package is in the contrib section.

daedalus

Package: iw
Recommends: ..., wireless-regdb, ...
--
Package: iwd
Recommends: ..., wireless-regdb, ...
--
Package: network-manager
Recommends: ..., wireless-regdb, ...
--
Package: crda
Depends: ..., wireless-regdb, ...

It might be worth to clarify here that "Devuan" is not an organisation that wants you to run particular software.

Devuan's contribution to the Linux world is to provide a package repository that includes all Debian packages as is, expect for those needing forking to avoid the systemd infestation.

If you find a bug in the openrc packages (which are not forked) you may report that to the Debian bugtracker.

Though your issue might rather be in the combination of packages you have installed and you are right to raise it here as this Devuan community may well include people who also use openrc packages.

Afaict there are two packages competing about the /usr/bin/python pathname, namely packages python-is-python2 and python-is-python3.

I think the upshot for this was that python3 changed a lot in syntax as well as in data representations from python2 and at that time it was considered wrong to use the plain "python" in their she-bang. In support of that the python installations stopped committing to that version choice and instead offered the choice as different packages.

Apparently some desktop environment(s) might want to make that choice for us, but technically it remains a user choice in Devuan daedalus.

I can't help you for runit, but I'm very interested in learning how to de-brick after an attempt to move the OS onto the eMMC.

Note that the VT switching patch for xserver-xorg-core has been applied for daedalus.

A normal upgrade brings it in, if your sources.list includes daedalus-proposed-updates.