Enabling software audio mixing with ALSA required copying and pasting a small handful of lines into your ALSA config file and just worked. Most of PulseAudio's hardware problems were caused by it having weird and unnecessary expectations, like wanting to know the exact sample being played by the hardware or expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes.

PulseAudio also had pretty awful code quality in general. For example, I ran into a crash where the resampling code was trampling past the end of the buffer and it turned out that every stage of the audio conversion process - resampling, channel conversion, and so on - made assumptions about where it was in the process and what sample rate, buffer size, channel count etc it should have on its input and output based on members of a shared struct that were used by multiple stages in different ways. At some point the developers had accepted a patch which changed this order without fixing half the resamplers - and which said it was incomplete in the commit message - and this had somehow made it into the release I was using. One of the unfixed resamplers was the one used for VU meters in mixer apps, because that was implemented as a resampler for some reason. Also, all of this code had basically zero comments. Oh, and reverting the patch didn't even fix the crashes for me so presumably there was some other problem somewhere. Oh, and on top of that there were no stable bugfix-only releases of PulseAudio, so even if it did get fixed upstream it'd come with a bunch of new non-bugfix changes with the same level of quality and scrutiny.

The irony is that during that same time, FreeBSD somehow offered sound working out of the box, complete with input mixing, and without anything like ALSA.

This is factually false in my case since ALSA alone has always been fine, no issues. And since I switched (with the same hardware) pipewire also works just fine. But pulseaudio (pa+alsa ofc) is just simply broken on my archlinux install.

EDIT: also when pulseaudio breaks you just do `pulseaudio --kill ; pulseaudio --start` Does this really reset the hardware/firmware? I doubt it; it's just configured poorly for my hardware why is that hard to believe?

It is probably the driver that leads to have pulse audio use 10% of the CPU of a quadcore when doing nothing / not playing any media?

Also, probably the driver that regularly confuse it's inputs and outputs settings...

Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does restarting the userland sound daemon reset the drivers operating in kernel space? How would that work?