The Linux audio stack demystified (and more)

Original Article ↗ Hacker News Discussion ↗

History and perceived “mess” of Linux audio

  • Many recall progression: OSS → ALSA → ESD/artsd → PulseAudio → PipeWire, with years of breakage, latency and odd behaviors (e.g., HDMI switching, games with no sound).
  • A classic “Linux audio mess” diagram is referenced; some say it still reflects reality, others argue most of that complexity is now historical.

Role of ALSA, PulseAudio, JACK, and PipeWire

  • General agreement: ALSA is kernel-level drivers plus a user‑space library.
  • Confusion arises because some descriptions imply PipeWire doesn’t need ALSA; multiple commenters assert this is wrong and that PipeWire uses ALSA to drive hardware, while also shimming ALSA and Pulse APIs.
  • PipeWire presents itself as unifying PulseAudio and JACK, offering one server for desktop and low‑latency/pro‑audio use; JACK-like graph routing and video support are highlighted.
  • Some emphasize that older components (ESD/artsd, OSS) are largely gone; others note many user‑space APIs (JACK, OpenAL, portaudio, gstreamer, etc.) still coexist.

User experiences: from “flawless” to “unusable”

  • Positive reports:
    • On several mainstream distros (especially Fedora and recent Ubuntu), audio “just works”: Realtek onboard, Bluetooth headsets, HDMI, conferencing, DAWs, multi‑MIDI setups.
    • PipeWire seen by many as a major improvement over early PulseAudio, with better Bluetooth handling, unified tooling, and fewer hacks.
  • Negative reports:
    • Others experience frequent issues: device switching failures, Teams/Zoom problems, robotic Bluetooth audio, suspend/resume breakage, weird channel mappings, Realtek quirks, and DAWs or synth stacks freezing systems.
    • Some professional‑audio users still prefer plain ALSA or JACK for lowest latency and predictability, avoiding Pulse/PipeWire entirely.

Design debates and open issues

  • Single‑client ALSA is blamed by some as the root cause; others argue multiplexing belongs in user‑space daemons (Pulse/PipeWire), mirroring macOS/Windows models.
  • Concerns include:
    • Opaque channel mapping and naming, especially for multi‑channel/pro‑audio interfaces.
    • Fragmented tooling and fast‑moving PipeWire CLI/GUI ecosystem that makes documentation go stale.
    • Accessibility complications when different screen readers use different layers.
  • There is disagreement over how “unified” things really are: some say PipeWire has effectively cleaned up the stack; others say it mainly swapped Pulse for PipeWire while the proliferation of APIs remains.