[Avshalom]

Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it.

Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.

[gf000]

Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.

[eqvinox]

That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.

That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.

[gf000]

My point wasn't that pulseaudio is flawless, it's just that it has a much worse name than it deserves.

[Izkata]

Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code.

* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.

[gf000]

So one audio server managed to provide a shim for another audio server, great.

But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.

[Izkata]

My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.

[pezgrande]

Interesting... didn't know this part of Linux history. I remember complaining about pulseaudio crashing a lot though ha. Thanks for sharing it.

[Jnr]

Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.

I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things.

I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.

[Avshalom]

Important to people being happy now is that Lennart Poettering didn't write pipewire.

Also having a bunch of things barely held together with duct tape is part of the philosophy.

[account42]

> Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.

Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted.

I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles.

But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC.

And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon.

Meanwhile ALSA with an up to date default dmix configuration worked just fine.

[Jnr]

When it comes to incorrect profiles, I suggest making a pull request to alsa-project/alsa-ucm-conf with correct configuration. I had similar issue with my audio interface a couple years ago but it was quickly merged and now it works better than on Windows or macOS.

Before that I did have custom config, it was not that hard to set up, there are great examples and explanations on Arch wiki: https://wiki.archlinux.org/title/PipeWire

[adjejmxbdjdn]

So he creates a program that was good enough that pretty much everyone started using it.

And he complained about a lot of dependencies but then went and actually wrote fixes/solutions for them that was so good that nearly everyone started using and even depending on it.

It sounds like the people who were sitting on the sidelines complaining about his complaining had ample opportunities to write better alternatives than the programs he wrote but didn’t do so. Instead they relied on character attacks and FUD (well, except the folks who developed pipewire), while Poettering wa engage in elite hacking by implementing solutions and letting users and distro makers decide whether they wanted to use those solutions.

I don’t see how Poettering is the villain here.

[nottorp]

> I don’t see how Poettering is the villain here.

Poettering seems to be good at politics. Where politics means having his way.

Not so much at writing working code, or interoperability.

[ahartmetz]

>good at politics

A son of GDR diplomats, according to an old version of his Wikipedia page. That information seems to be memory-holed now. Now you only find that he grew up in South America without any hint of a reason.

[Avshalom]

Look, I was in CS101 back in those days so I'm not really qualified to say who was right about where/with-what responsibility for bugs lied. Maybe he was completely right and just kind of a dick about it. I'm just reporting that no one liked him and that carried over to the introduction of systemd.