Resampling is necessary in many run-of-the-mill scenarios. If all you want is to play one stream, that can be done with no resampling. If you want the kind of automagic mixing of multiple inputs and outputs with hotplugged devices over bluetooth and dog knows what else that people tend to expect from a modern system... Some resampling will be happening somewhere.

This is one advantage of pipewire over pulseaudio or ALSA DMIX, it tries quite hard to match your stream to a samplerate your hardware supports, and to never downsample anything if it can be avoided.
Whether or not pipewire's spa resampler is suitable for the cases where it is needed... That's up to your (presumably bat-like) ears to decide.

In general though, unless your resampling algo is really bad (or you're using a SoundBlaster 16), your speakers and listening environment will be doing more to screw up reproduction than anything on the source end.

That'll work, but it probably won't play nice with a multi-user/multi-seat system.

Killing processes is a dirty hack to kill lingering pipewire processes after a user logs out - which will tie up the sound devices so that they will have no audio if they log in again. Dirty, because it doesn't solve the root problem of making sure pipewire terminates when the launching user logs out (of possibly multiple sessions etc.).

That's one of the things we need real user-services for, this kind of shell-hackery is all well-and-good for a single-user box, but unix/linux is and always has been multi-user. Getting that to work properly means tying the pipewire daemons to the login seat lifecycle somehow, or hacking pipewire to run as a system-wide service (which it absolutely wasn't designed for).

I already am "elsewhere". I have exactly one headless box still running Devuan, and if the next upgrade is as much of a disaster as I expect it will be, that one will move to Gentoo as well.

As for being pissed... I'm being told to "go code" by a self-important bureaucrat who can't code, and directed to dead channels to engage with absent devs in non-existent onboarding processes.
And they wonder why anyone who might contribute gives up and goes elsewhere. That airfare to amsterdam go is so proud of? That could have paid someone to start sorting out this mess.

Case in point, let's recap 24 hours of the devuan-dev channel:

Let's see... No development, one guy giving up because there's nobody around, and golinux dropping some bureaucratic chaff nobody cares about.
And this is right on a major release window. Trixie just dropped, where is everyone?

Why bother? Even the most stalwart rats must be making for the mooring lines by now, with all possible haste. Might as well join them, no?

Upstream fail2ban already has compatibility with python 3.13 (inc. bundling the async modules removed with python 3.12), said upstream version (1.1.0) is in trixie, and there appear to be no relevant reports on the Debian BTS...

If you're going to claim "well known and all over the internet", perhaps provide some examples?

Given that the only hits I can get for that exact error are 1: this thread, and 2: an artix user from 5 years ago, and there's no noise about this at all over on FDN, I'm far more inclined to think this has to do with python-systemd and Devuan packaging / shipped configs than anything else.

Ed. Yup, sure enough, again:

$ diff fail2ban_1.0.2-2_all/data/etc/fail2ban/paths-debian.conf fail2ban_1.1.0-8_all/data/etc/fail2ban/paths-debian.conf 
30a31,41
> 
> # In Debian, these services will log to the journal via syslog, so use the
> # journal by default.
> syslog_backend = systemd
> sshd_backend = systemd
> dropbear_backend = systemd
> proftpd_backend = systemd
> pureftpd_backend = systemd
> wuftpd_backend = systemd
> postfix_backend = systemd
> dovecot_backend = systemd

$ diff fail2ban_1.0.2-2_all/data/etc/fail2ban/jail.d/defaults-debian.conf fail2ban_1.1.0-8_all/data/etc/fail2ban/jail.d/defaults-debian.conf
0a1,4
> [DEFAULT]
> banaction = nftables
> banaction_allports = nftables[type=allports]
> 
1a6,7
> backend = systemd
> journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd

That's not going to work, now is it? Nice job Devuan packaging team merging stuff from debian without testing it bot, great catch. Definitely fixing all the systemd things for this premiere systemd-free distro.

@OP, make sure all your jails are using the 'polling', 'pyinotify' (if you have that installed) or 'auto' backends. This might not be your problem, but I suspect it is based on where that error appears to be coming from...
Either way though: Blindingly obvious excalibur packaging fail. If it doesn't cause problems here, it will later.

So, IOW "There is no formal procedure to become a Devuan contributor."

Why do I even bother. Guess I'll go see if #devuan-dev is still a whole bunch of resounding silence.

Good to know I'm not the only one who has noticed.

The answer(s) to the original question and comments on the situation in general have been covered ad-nauseam in another thread, what else is there to do?

I've been pissed with this whole situation for some time, because nothing at all appears to be happening, and the standard tag-line around here when it comes to systemd-dependent packages is "just don't use them"... While the distro steadily looses functionality and the users steadily loose options.
Systemd is not going to go away, and burying our heads in the sand isn't going to fix anything.
User-units are a thing, and we need a solution. Define what that solution should look like and someone might just provide it.

EDX-0 dreamed up a whole user-init system, is Devuan interested? Is this the solution we should be contributing to? Who knows, there's nothing but silence from leadership.

Need more devs? Sure, every project needs more devs. You don't get more devs by bitching about it, you get them by training up more devs.
That means setting out what needs doing, how to go about doing it, and how to get it into the distro, then providing hands-on guidance and mentoring to make sure it doesn't break anything.

And yet, here you are shouting at others for not doing those things.

Yes yes, I'm sure you're very important. We were talking about "sanitizing" packages, were we not? What do airfares have to do with that?

gentoo-pipewire-launcher is intended to be started per-user as part of session startup (e.g. xdg-autostart or xinitrc), not by openrc.
As I said above, pipewire is intended to be started by systemd user units for each user login, not system-wide by init as root. Current openrc releases do have (experimental) user-unit support which could handle this... But this is Devuan we're talking about here so good luck finding current anything in the repos.

To quote the Gentoo wiki page (which you should also read completely):

Using the gentoo script is one option, others are discussed in the thread I linked earlier. How you actually launch any of those depends on your graphical session, for KDE on wayland, xdg-autostart is probably easiest.

FWIW, this was my suggestion, and is what I'm using right now on Gentoo (It works well enough I haven't gotten around to moving it over to openrc user-units). Make of it what you will, it does require backporting a not-ancient daemon version from unstable.

Indeed. While it is likely a dead horse, I'll flog it some more here: Devuan, as a supposed leader in systemd-free distros... Does precious little leading.
Where real work is needed to get things working without systemd, solutions are lifted from Gentoo (eudev, elogind, opentmpfiles etc.). Everything else is just banning packages rather than fixing them, or shipping broken setups like we see here with wayland and pipewire.
I have asked repeatedly what Devuan's direction and preferred solution for user-units is, and all I get is a bunch of "nothing, wait for Debian to fix it" wilful inaction.

That's not how pipewire is meant to be started.

That's not even remotely how pipewire is meant to be started.

Failure to read the documentation or search the forum.

They do, but they're starting only one part of it, manually, and with sudo for maximum borkage (sudo is always the answer ). It can't find it's runtime directory, because that env is not set for root (even if sudo propagated those vars, which it doesn't).
Even if it could, sound still won't work without wireplumber (and pipewire-pulse if you want the KDE mixer and stuff).

Well it's an out-of-tree DKMS module, so yeah, obviously, if you don't need it just remove the package.
I assumed that since you had it installed, you wanted it.

... Will have exactly the same problem. That's what I said above: Kernel packages and DKMS packages need to be in sync, so if you run a newer kernel you need to backport newer versions of any additional drivers as well.

This is not "kernel hacking", it's Debian packaging 102 and the usual stuff you need to be aware of if you deviate from the stable release or add non-devuan packages.

LMGTFY....
https://wiki.debian.org/AptConfiguration#Using_pinning
https://douglasrumbaugh.com/post/apt-pinning/

Well for one,

172.22.22.05	colossus.home colossus

"172.22.22.05" isn't a correctly formatted IP address...
And for two,

getent hosts

would have made it fairly obvious whether or not your /etc/hosts file was the problem, since it returns only valid entries.

$ printf '%s\n' "* File:"; cat /etc/hosts; printf '%s\n' "* Reality:"; getent hosts
* File:
127.0.0.1 localhost damnation.lan damnation

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.22.22.05    colossus.home colossus

* Reality:
127.0.0.1       localhost damnation.lan damnation
127.0.0.1       ip6-localhost ip6-loopback

$ printf '%s\n' "* File:"; cat /etc/hosts; printf '%s\n' "* Reality:"; getent hosts
* File:
127.0.0.1 localhost damnation.lan damnation

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.22.22.5     colossus.home colossus

* Reality:
127.0.0.1       localhost damnation.lan damnation
127.0.0.1       ip6-localhost ip6-loopback
172.22.22.5     colossus.home colossus

As I said, networkmangler is a red herring and it was only brought up because everyone here loves to hate on it.
I mean I kinda hate it too, but going straight to "Damn new software, the old ways were better, life was simpler, bloody clouds etc. etc." before even trying to investigate the problem is plain ridiculous.

FFS people, get a grip. Networkmangler will mangle /etc/resolv.conf if it is configured to do so. You can shout about it, you can remove it... Or you could just do a 10 second search and set it up to do what you want.

Indeed. While there are many other ways to configure networking on a mobile device, networkmangler + modemmangler + [all the 50 plugins] does make a certain amount of sense.
Unfortunately, the prevailing attitude here seems to be shouting "[x] is crap, I hate [x], why does this new complicated [x] exist" rather than addressing the question in a sensible manner.

Oh, I see how it is.
People whose politics don't align with yours or you otherwise disagree with are "assholes", "parasites" or "facists", and saying so is fine... But calling out shallow clickbait for what it is is "harsh", because you agree with the the creator's views generally.

You want to play in the "Linux news videos" corner of the interwebs, you'll find the vast majority of it is regurgitated, rehashed nonsense from other sources.
Lunduke's videos are him reading his own blog posts about things he read on other blog posts, Brodie's are him making excited faces and waving his hands around while reading release announcements or clicking around other people's websites. Neither are particularly interesting, nor particularly creative.

As for muppets, you have seen Brodie's video thumbnails, right? I mean, if you go out of your way to pose like one...

Of course it isn't, and anyone with a clue about programming knows it without watching some random not-very-technical video.
Rust is a tool like any other language, what you do with it is up to you, and using it doesn't magically make your code good (though it does make it harder to write particular kinds of bad).