You Can’t Hear Anything—and It’s Not Your Fault

You plug in headphones.
Nothing.
You unplug them again.
Still nothing.
The speakers are muted.
The system says they aren’t.
You check volumes. You restart Pulse. You restart PipeWire.
You restart your whole damn session.
And still—no sound.

That’s just a Tuesday on Linux audio.

Sometimes the device shows up and just won’t play anything.
Sometimes it does—but stutters constantly like it's on a failing cassette tape.
Sometimes laptop speakers never work at all unless you run a six-line hda-verb incantation copied from a 9-year-old mailing list post.

Sometimes, the system boots up with everything at 0% volume.
Why?
Because PulseAudio once had a patch to mute sound on boot.
Then someone reverted that patch because it was breaking things.
Then someone re-applied it.
Then someone re-reverted it.
Then someone added a workaround that cancels the revert of the unmute of the mute.

This is real. This is production. This is Linux audio.

A Brief History of This Disaster

It started simple.
ALSA was the kernel-level driver layer: Advanced Linux Sound Architecture.
It’s still here.
It still runs the hardware.
But back in the early 2000s, people realized ALSA wasn’t enough. It couldn’t mix audio from multiple sources. It couldn’t route sound across apps. It was raw, low-level, and unforgiving.

So we got PulseAudio.
It was supposed to be the layer on top of ALSA—handling device routing, per-app volume control, hotplug support, etc.
Except it was buggy. And laggy. And didn’t always work.
But everything depended on it.

Fast forward to now: Pulse is deprecated in favor of PipeWire—and this time, it’s actually good.

PipeWire, together with WirePlumber (not pipewire-media-session), finally gives us a modern, low-latency, graph-based audio and video system. Bluetooth profiles? Handled. Device routing? Solid. Policy control? Configurable. It fixes real problems that PulseAudio never could.

But here's the problem: the software ecosystem hasn't caught up.

Most apps still expect Pulse. They talk to pipewire-pulse, the compatibility layer—not PipeWire itself.
The stack is clean. The interfaces are better. But the expectations are still stuck in 2012.

And for blind users, that matters. Because even with PipeWire working beautifully, we still hit problems like:

• Device indexes aren’t simple numbers anymore—they’re long UUID-like IDs, which makes scripting harder.
• Audio is still tied to your user session. That means root can’t speak—just like with Pulse.
• Tools like espeakup or fenrir still require config hacks to forward audio from root to your user via WirePlumber.

So yes—PipeWire is a massive improvement. But the legacy Pulse model still shapes how software behaves, and the new stack inherits the same fundamental issue: your sound only works if your user session works. And that’s the exact point where blind users often lose access.

And even beyond that:

You still need Pulse for legacy apps.
You still need ALSA for direct hardware access.
You still need JACK for pro audio tools that never moved on.

So the result? A modern core surrounded by the same old mess.

Debugging Hell: Audio Edition

When audio breaks on Linux, it doesn’t crash.
It doesn’t throw a friendly dialog.
It doesn’t log anything useful.

You just… don’t get sound.

You start running commands:

pactl list sinks
pactl list sources
alsamixer
systemctl --user status pipewire
journalctl -xe

Maybe you see a device. Maybe not.
Maybe it shows up as “dummy output.”
Maybe it shows up as working—while emitting nothing.

If you're lucky, pavucontrol shows the wrong profile and you can fix it.
If you're unlucky, there's no fix. Or the fix doesn’t persist. Or the profile isn't even listed.

Sometimes PipeWire crashes and restarts.
Sometimes it doesn't.
Sometimes Pulse is still running and you didn’t notice.
Sometimes two instances of PipeWire are running—because of a race between your display manager and your session manager.

Sometimes Bluetooth just doesn’t work unless you restart the service in exactly the right order with a magic D-Bus incantation.
Sometimes your speakers disappear when you unplug headphones.
Sometimes they come back muted.
Sometimes you unmute them and they still don’t play—because Pulse remembered a per-port volume of zero from 3 years ago.

And this is just normal desktop audio.

Firmware, UCM, and the Dark Corners

Now let’s talk about laptops.
Not desktops.
Not audio interfaces.
Laptops.

Because here, you get firmware bugs and undocumented quirks.

Your speakers might not work unless you boot with snd-hda-intel.model=laptop.
Or dell-headset-multi.
Or maybe auto.
Or maybe that breaks your microphone.

You’ll find a forum post that says:
“Add a ~/.asoundrc file with these three lines.”
And maybe that works.
Or maybe it breaks every other audio device.

Then there’s UCM—Use Case Manager.
Not documented. Not stable. Not complete.
It’s how Pulse and PipeWire talk to ALSA, and how ALSA talks to your actual hardware pins.

If the UCM file is wrong?
Your device might show up with no outputs.
Your headphones might get routed to the mic jack.
Your speaker might be marked “available” but play nothing.

Fixing this means digging through /usr/share/alsa/ucm2/, reading files written in a half-broken config language no one maintains.
And if your laptop isn’t listed?
Good luck.

Why This Is Even Worse When You’re Blind

For sighted users, audio issues are annoying.
For blind users, they’re catastrophic.

If Orca doesn’t start, and you don’t get sound?
You don’t know why.
There’s no visual feedback.
There’s no error message you can click.
There’s no fallback.

You’re just locked out.
You can’t tell if your machine booted.
You can’t tell if you’re at a login prompt.
You can’t even tell if your system is still on.

You might be in a broken session.
You might be in a panic state.
You might just have no output.
And you have no way of knowing.

This isn’t inconvenience.
It’s exclusion.

And the worst part?
Sometimes the sound comes back.
And you never find out why it broke in the first place.

Because nothing logs it.
Nothing warns you.
Nothing explains it.
It just starts working again… until it doesn’t.

This is the state of audio on Linux in 2025.

And somehow we’re told this is fine.

When the UI Doesn’t Talk, and the CLI Barely Listens

Let’s say you want to adjust volume.
You do what any normal person would do: you open a graphical mixer.

Except most graphical mixers on Linux:

• Don’t label their sliders correctly for screen readers
• Don’t expose device names properly
• Are built on toolkits with broken AT-SPI support
• Don’t announce focus or selection at all

If you’re blind? You’re just guessing which slider is which.
Orca might say “slider” or “application” or nothing at all.

So you fall back to the terminal.

Except now your desktop is broken. Audio’s gone.
So you SSH in. Or you plug in a serial console.
Or you switch to another TTY—if your distro even configures that properly.

Now what?

You try:

pactl list sinks
pactl set-sink-volume @DEFAULT_SINK@ 75%

Or worse:

pacmd
>>> list-sinks
>>> set-default-sink 1
>>> set-sink-volume 1 0x10000

Except pacmd is undocumented, unforgiving, and interactive.
You can’t use it easily over serial.
You can’t script it.
You have to memorize hex values for volume and sink indexes that change every boot.

And pactl?
It’s only slightly better.

Want to move all audio streams to a new device?

for i in $(pactl list short sink-inputs | awk '{print $1}'); do pactl move-sink-input $i 1; done

You have to parse pactl list, grep for card names, match up device IDs, and hope the syntax hasn’t changed.
All without sound.
All without feedback.
All without any guarantee that it’ll work.

And all this because the nice graphical mixer either didn’t expose the volume control to Orca or crashed on startup.

This isn’t a fallback.
It’s a punishment.

Bluetooth: Still Just Voodoo

Then there’s Bluetooth.

You pair your headphones.
Maybe they connect.
Maybe they don’t.
Maybe they show up in Pulse but not PipeWire.
Maybe they play audio—but only in HSP mode, which sounds like a tin can in a tunnel.

Maybe they work… until you reboot.
Then you have to delete and re-pair the device.
Or restart bluetoothd.
Or kill and restart wireplumber.
Or re-enable the bluetooth-audio module manually with a script you copied from Stack Overflow.

Even when it works, the latency is inconsistent.
Volume levels reset.
The connection drops mid-sentence.
Or it switches to HSP randomly and destroys your microphone.

And this is with BlueZ—the Linux Bluetooth stack that’s been around for years, is included in every distro, and still doesn’t Just Work.

There are wrappers.
There are helpers.
There are DBus APIs and agent scripts.
None of them are consistent.
some of them are accessible.
And none of them are reliable.

It feels like Bluetooth support on Linux is one flaky daemon away from collapse at all times.
And it’s been that way for over a decade.

You Call This a Stack?

People call it a stack.
But it’s not.
A stack implies layers. Order. A single interface at each point.

This is not a stack.
This is a tangled mess of everything ever built for Linux audio still being required right now because no one can kill anything off without breaking something else.

You want to play sound? You need:

• ALSA, because it’s the actual driver
• PipeWire, because it’s the new standard
• Pulse emulation, because most apps still use Pulse
• ALSA plugins, because some things bypass PipeWire
• JACK shims, because a few pro audio tools never moved on
• And config files for all of it—if they even exist

This isn’t backwards compatibility.
This is a graveyard, and we’re all just camping in it.

The Real Cost of Sound That Doesn’t Work

Linux audio doesn’t just fail.
It wastes your time.
It gaslights you.
It makes you doubt your hardware, your config, your kernel, yourself.

Because you know it should work.
It works on other machines.
It worked yesterday.
It works after three reboots.
It works if you reset Pulse.
It works until it doesn’t.

And when it breaks?

• It doesn’t explain why
• It doesn’t log useful errors
• It doesn’t surface diagnostics
• It doesn’t give you tools
• It just stops talking

And for a blind user, that means the computer is gone.
There’s no GUI fallback.
There’s no error window.
There’s no log viewer.
There’s just silence.

And we’re expected to fix this blind.

You Shouldn’t Need a Specialist to Hear Your System

It shouldn’t be this way.
You shouldn’t need to install three compatibility layers, patch a udev rule, reboot twice, pray, and then maybe get working sound.

You shouldn’t need to be an audio systems engineer just to watch a video or hear a login prompt.
You shouldn’t have to file a bug just to use your speakers.
You shouldn’t have to script volume restoration, restart services by hand, and know the difference between alsa, aplay, pw-play, and paplay.

But here we are.
And until someone tears this down and rebuilds it for real accessibility, it’s only going to get worse.

Coming next:

Post 3 – Speakup, BRLTTY, and the Forgotten Infrastructure of Console Access

Because when your GUI fails and your audio fails and your display server eats itself,
the console was supposed to save you.

But even that isn’t safe anymore.