To@Altoid
I know recompiling packages isn’t everyone’s idea of fun, but this one’s worth it. Rebuilding libasound2-plugins without PulseAudio isn’t just a technical tweak — it’s a small act of digital self-determination. No more phantom plugins trying to phone home to a server that isn’t there. No more audio routing chaos. Just clean, direct ALSA control.

And once it’s done, it stays done. No files sneaking back on update. It’s stable, silent, and free.

The process? A few commands, one .deb, and you’re set for life. Freedom isn’t always easy — but it is simple.
_https://dev1galaxy.org/viewtopic.php?id=7523

$ ls -1 /usr/share/alsa/alsa.conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf

$ ls -l -1 /etc/alsa/conf.d
total 0
lrwxrwxrwx 1 root root 44 Jul  1  2024 10-rate-lav.conf -> /usr/share/alsa/alsa.conf.d/10-rate-lav.conf
lrwxrwxrwx 1 root root 46 Jul  1  2024 10-samplerate.conf -> /usr/share/alsa/alsa.conf.d/10-samplerate.conf
lrwxrwxrwx 1 root root 45 Jul  1  2024 10-speexrate.conf -> /usr/share/alsa/alsa.conf.d/10-speexrate.conf
lrwxrwxrwx 1 root root 48 Jul  1  2024 50-arcam-av-ctl.conf -> /usr/share/alsa/alsa.conf.d/50-arcam-av-ctl.conf
lrwxrwxrwx 1 root root 40 Jul  1  2024 50-jack.conf -> /usr/share/alsa/alsa.conf.d/50-jack.conf
lrwxrwxrwx 1 root root 39 Jul  1  2024 50-oss.conf -> /usr/share/alsa/alsa.conf.d/50-oss.conf
lrwxrwxrwx 1 root root 47 Jul  1  2024 60-a52-encoder.conf -> /usr/share/alsa/alsa.conf.d/60-a52-encoder.conf
lrwxrwxrwx 1 root root 41 Jul  1  2024 60-speex.conf -> /usr/share/alsa/alsa.conf.d/60-speex.conf
lrwxrwxrwx 1 root root 41 Jul  1  2024 60-upmix.conf -> /usr/share/alsa/alsa.conf.d/60-upmix.conf
lrwxrwxrwx 1 root root 44 Jul  1  2024 60-vdownmix.conf -> /usr/share/alsa/alsa.conf.d/60-vdownmix.conf
lrwxrwxrwx 1 root root 46 Jul  1  2024 98-usb-stream.conf -> /usr/share/alsa/alsa.conf.d/98-usb-stream.conf

$ apt-file find 99-pulseaudio-default.conf.example
libasound2-plugins: /etc/alsa/conf.d/99-pulseaudio-default.conf.example

But ALSA it not without blame, while it works well it has really awful/cryptic documentation which probably is the main reason why most people don't understand all of it's capabilities (myself included).

The API documentation is an absolute nightmare. In fact, the only real "documentation" is the source comments. They get scraped by doxygen and posted to the ALSA site, but most of the links from the index page just go to blank pages. It's been this way for years!

At least there's some online documentation for the C API, I guess. ALSA has an official set of Python bindings which wrap essentially the entire C API. The ALSA devs call it "pyalsa," but if you search for that name, you will find only a completely unrelated, unfinished, decade-old hobbyist project. (in fact, I think there might be two of them!) There is absolutely no online documentation for the real Python ALSA bindings. In fact, the only way to read the documentation is from within Python itself.

Unfortunately, the ALSA bindings also seem pretty buggy. get_volume works, but get_volume_dB always seems to return zero. Maybe I'm using it wrong, but the sparse documentation certainly doesn't give any hints. Attempting to use the mixer callback facility invariably results in the Python interpreter crashing.

I saw some confusing things when I was looking at other people's mixer code. There seemed to be this persistent belief that you had to open the snd_hctl device before opening the snd_mixer interface. I have no idea where they got this idea, but it's completely unnecessary.

Even the ALSA devs don't fully implement their own API. I have a card that shows the "Mic Boost" control twice in alsamixer. The element shows up during both capture and playback enumeration, but it's marked as "common." The application should check for this attribute and only show the control once.

In my Daedalus install (originally Jesse ca. 2017 and dist-upgraded) /etc/alsa/conf.d has 12 symlinks to the same number of [*.conf] files in /usr/share/alsa/alsa.conf.d plus a file not linked to any other: 99-pulseaudio-default.conf.example

$ ls -1 /usr/share/alsa/alsa.conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
50-pulseaudio.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf
$ 

$ ls -1 /etc/alsa/conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
50-pulseaudio.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf
99-pulseaudio-default.conf.example
$ 

$ cat /etc/alsa/conf.d/99-pulseaudio-default.conf.example
# Default to PulseAudio

pcm.!default {
    type pulse
    hint {
        show on
        description "Default ALSA Output (currently PulseAudio Sound Server)"
    }
}

ctl.!default {
    type pulse
}
$ 

Best,

A.

But ALSA it not without blame, while it works well it has really awful/cryptic documentation which probably is the main reason why most people don't understand all of it's capabilities (myself included).

1. The Setup 
  For years, ALSA has quietly shipped with a fully functional software mixer — powered by dmix, dsnoop, and asym — enabled by default in Debian, Devuan, and their derivatives. Full-duplex audio (simultaneous playback and recording) works out of the box. You can test it with a simple terminal command:

arecord -f cd -V mono | aplay

  If you see a VU meter dancing merrily across your screen, congratulations — your system has been quietly and competently handling bidirectional audio without any fuss. No configuration required. It just works.
 
2. The Misunderstanding 
  Enter the developers of cubeb, the audio backend used by Firefox and other web-centric applications. In their implementation (cubeb_alsa.c:1407–1455), they appear to have treated ALSA not as a mature, self-sufficient audio architecture, but as a bare-bones fallback — a last resort when PulseAudio isn’t available. Rather than querying ALSA’s actual device topology using snd_device_name_hint(), they sidestepped proper enumeration entirely. The result? A single, fictional “default” device is reported — not discovered, but invented.
 
3. The Irony 
  Here’s the punchline: cubeb does successfully open and use ALSA’s default PCM device (cubeb_alsa.c:76), which in turn leverages the very same asym plugin that seamlessly routes playback through dmix and capture through dsnoop. The system works — it’s using the full power of ALSA’s default configuration. 
  Yet, when asked to describe what it’s using, cubeb confidently declares:
 
- “This device supports 10,000 channels.”
- “Latency? Oh, zero — perfectly instantaneous.”
- “Sample rate? A firm 48,000 Hz, and no questions asked.” 
  It’s like a waiter who serves you a perfectly cooked meal from a five-star kitchen but insists the dish was microwaved and made for a hundred people.

4. The Cascade 
  This small fiction snowballs into a full-blown mythos:

- Community wikis (Gentoo, Arch) propagate elaborate ~/.asoundrc configurations, as if the default setup were broken or incomplete — when in fact, most of these configs downgrade functionality, disabling dmix, dsnoop, or full-duplex support.
- Official documentation (e.g., Debian Wiki) points users to /etc/alsa/conf.d/, a directory that often doesn’t exist or isn’t used, while the real defaults live in /usr/share/alsa/.
- The ALSA Wiki itself offers examples that encourage users to reinvent the wheel — often poorly — reinforcing the idea that ALSA needs fixing.
- A widespread belief persists that ALSA cannot function without PulseAudio — despite decades of evidence to the contrary.

5. The Punchline 
  And so, the final irony:

- YouTube videos play without issue — simple playback, no problem.
- Zoom’s standalone app works flawlessly — it speaks ALSA’s language directly, bypassing the fiction.
- But Zoom’s web client fails — not because the audio system is broken, but because cubeb lies about what it sees. It doesn’t expose the real capabilities of the default device, leaving the web application blind.

It’s a classic farce: the hardware works, the kernel works, ALSA works, and even cubeb sort of works — yet the whole edifice collapses under the weight of misinformation.

The Absurdity

The true absurdity lies in the fact that everyone is correct — in their own little world.

- ALSA functions perfectly — proven by aplay and arecord running in tandem.
- cubeb opens the audio device successfully — it’s not failing, it’s just lying about it.
- Zoom’s native app works because it doesn’t rely on this charade — it talks to ALSA like a grown-up.
- Users follow the documentation — only to be led down rabbit holes of unnecessary configuration.

It’s a Monty Python sketch in code form: a perfectly functional system rendered unusable not by bugs or limitations, but by a cascade of assumptions, omissions, and polite fictions. Everyone’s following the rules. The rules are wrong.

Notes

The “British sitcom with a touch of absurdity” comparison is apt. This isn’t a tragedy — it’s a comedy of errors. Well-meaning developers, decades of misleading documentation, and a “secret” that was never really hidden — just overlooked — have combined to create the illusion of brokenness.

The solution was there all along: the default ALSA configuration is sufficient. It enables full-duplex, software mixing, and robust device routing. No extra tools, no PulseAudio, no custom configs — just arecord | aplay and a quiet sense of satisfaction.

The real joke? We spent fifteen years fixing something that wasn’t broken — because no one thought to just ask what was already working.