People cursed the name for years, because it exposed all of the terrible, glitchy audio hardware drivers and refused on general principle to work around the issues to the degree that previous audio solutions had. And the result was that while the experience was inconsistent and buggy for years, it did eventually drag the Linux audio stack into a better place.
Comparing JACK and PulseAudio is like comparing apples and oranges. And honestly, JACK by itself is unsuitable as an audio server for general desktop usage.
JACK doesn’t support device hotplug (ya know, connecting and disconnecting a headset, something most of us do) and it also doesn’t support multiple applications generating audio without the user having to configure how audio is mixed.
JACK is designed for low latency in environments like Digital Audio Workstations (DAW) where you know 1) what audio hardware is present at all times, and 2) what applications are going to generate audio.
Many people who use/used JACK ran a PulseAudio bridge on top of it for every application that wasn’t the one or two applications that needed ultra low latency audio.
PulseAudio had some major warts, but JACK wasn’t some panacea that did everything better.
It also used a large multiple more memory than Alsa + basically any existing plausible combo of mixer software on top of alsa. While doing nothing. For no clear reason. And chewed processor cycles, while doing nothing. Back when 50MB was a meaningful amount of memory, and most machines were still single-core.
It was plainly really poorly-architected, just looking at its resource use patterns made this obvious in a heartbeat.
It also introduced fun new audio bugs and indeterminate latency. Which still haven't gone away entirely in 2026. To such an extent that any time I have an audio issue, I reflexively `pkill -9 pulseaudio` and about 99% of the time the problem just vanishes.
On the first machine where I had pulseaudio foisted on me - an 800mhz single core Duron - pulseaudio used literally 20% of my CPU time...
...At idle. When no audio was playing...
...To do software audio mixing which my creative labs audio hardware was capable of doing better and for free.
When I filed an issue with the pulseaudio people, saying "hey, you're wasting 20% of my CPU time at idle when no audio is playing because you're ignoring the fact that I have superior hardware that can do audio mixing for free", they closed the issue saying that pulseaudio wasn't meant to be used in situations where you have dedicated hardware for audio mixing.
The ALSA drivers for all the creative labs cards worked perfectly well. I never had any issues at all under ALSA, or under OSS before that.
I've had tons of issues with audio bugs once pulseaudio was introduced. To this day the most common solution to any audio issue I see is `pkill -9 pulseaudio`. And it solves the problem about 99% of the time.
People cursed the name for years, because it exposed all of the terrible, glitchy audio hardware drivers and refused on general principle to work around the issues to the degree that previous audio solutions had. And the result was that while the experience was inconsistent and buggy for years, it did eventually drag the Linux audio stack into a better place.