I'm also using and happy with Pipewire but I can't remember the last time I had a PulseAudio issue, across many systems.

My recollections of Linux audio issues are more from the days when one thing might want to use OSS and another ALSA and you might have to fiddle around and enable software mixing in some ALSA configuration files to get non-exclusive sound to work. And then some issues right around when Pulse first started to be a thing. But really it's been a "Just Works" for me for years and years.

Yeah, same; I can't help but think there is a vocal minority in these threads that thinks Pulse is broken.

I use Pulse for some pretty complicated stuff, too; I'll pipe individual streams to my speakers, if I want to show something to my SO (e.g., a reddit video) but want to keep, like, my music or my backgrounded game on the headset. I can do that with PA, and honestly pretty easily. AFAIK, no other system supports that, though admittedly I haven't used Windows in some time.

Far more complicated, I also have TTS bot I use in Discord sometimes, when I can't speak. PA allows me to push that into Discord; this is another thing I don't even begin to know how to set up on other systems. (The bot emits sound, so it's like a program playing sound, not a recording device. Discord thus doesn't recognize it as such. So I end up creating a fake input device, of sorts, and wiring the bot's output to that fake output (so it goes to Discord) but also to my own headset, so I can also hear the bot, as the TTS is far from perfect and will sometimes just make hilarious garbage of words.)

I also use Bluetooth, and that usually works. It certainly works more reliably with PA on Linux than it does w/ macOS, though it is my no means flawless. But that seems to be how bluetooth is: it sucks on every OS. There will be days it won't connect to Linux, and there will be days it won't connect to macOS.

I will say that Pipewire looks like it more solidly hits the nail: the thing I don't like is that PA doesn't really model audio as a graph of nodes. (PA's model is equivalent to a graph of nodes, but that it isn't just a graph of nodes makes it a lot harder to deal with and intuit.) For that reason I'm excited about Pipewire; I need to try it one of these days. PA would also be served by a better API; it is difficult to script against.

Also, systemd units are hands-down a more solidly engineered thing than the mess of shell scripts they replaced. I will take systemd+journald any. day. of. the. week. People that … want shell back — I honestly can't comprehend this. I've literally not had to deal for years now with a service wedging itself in because some daemon orphaned itself somehow between some unreliable mess of shell, pidfiles, and other hacks. Is systemd/journald perfect? No, I've spent time fighting it too. But it's a lot more productive than what came before, and the design is engineered to solve the problem at hand… which the shell mess was not.

For me Pulse was brutally broken for the longest time. Bit by bit most of the various glitches did get worked out, but the "pain points" of that process did leave me a bit bitter over how Pulse was really kinda "forced" on us long before it was "ready for prime time". Same with systemd, and same with the KDE3⇒KDE4 transition. All pushed too hard for widespread adoption too early in their development, while many of the worst bugs were still commonplace occurrences in daily usage.

Ever used a soundcard with more than two inputs and more than two outputs? Or better: that soundcard while also outputing audio via HDMI?

PA is ok if you use consumer software for consumer tasks. As soon as you go into the production side of things (or even do it live and/or for money) things can fall appart pretty quickly.

The vocal PA critics I know don't even complain about the way pulseaudio does things. They complain about the persistent problems this widely deployed piece of software still has after years in the field. And some of those problems are of conceptual nature.

I don't Pöttering really deserves the heat he gets (no dev would), but I sometimes wish that type of (usually male) programmer would just sometimes stay with the trouble and not ride of into the sunshine when things aren't a beautiful fresh sheet of white paper anymore, but a tangled mess.

Yes to both. My laptop has HDMI & TRS out. AFAIK, the soundcard is not capable of emitting to both HDMI & the TRS port simultaneously, but it's also not something I've ever wanted to do, so I'll admit that the limit of my use case there.

(I'll use a bluetooth headphone, if I want audio while pushing something to HDMI. Though I could see using TRS headphones being a nice to have, and I honestly don't know how to configure that, or if it is even possible, since it's all represented as one card in PA.)

While I'm no fan of Pöttering, I can certainly understand wanting to maybe "ride off into the sunshine" when the vast majority of humanity these days is more willing to tear down their fellow humans than they are to suggest or help with any sort of actual solution to any given problem. Makes even trying feel more than a little pointless.

> I'm still baffled by how something as basic as audio output can be eternally fragile in linux

Yeah, broken drivers.

You see, before pulseaudio came along, audio drivers were barely used and needed to be tuned for each use case. Most drivers barely implemented ALSA, almost none correctly. If you wanted fancy features (say; software input mixing, so that more than just one application can actually output sound) you needed to invest a lot of time.

By making all these fancy features (and more) more easily available, pulseaudio exposed all these bugs in the drivers.

And of course it got flak for that because the first software layer the user is confronted with is blamed if something's not working.

But actually - just as systemd - pulseaudio is a marvelous piece of code. That today we can get to an even higher level with PipeWire is to large degrees only possible because of pulseaudio.

Lennart Poettering is one of the most creative and influential system-space developers that Linux has. It's a shame that he's so maltreated by the peanut gallery.

Enabling software audio mixing with ALSA required copying and pasting a small handful of lines into your ALSA config file and just worked. Most of PulseAudio's hardware problems were caused by it having weird and unnecessary expectations, like wanting to know the exact sample being played by the hardware or expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes.

PulseAudio also had pretty awful code quality in general. For example, I ran into a crash where the resampling code was trampling past the end of the buffer and it turned out that every stage of the audio conversion process - resampling, channel conversion, and so on - made assumptions about where it was in the process and what sample rate, buffer size, channel count etc it should have on its input and output based on members of a shared struct that were used by multiple stages in different ways. At some point the developers had accepted a patch which changed this order without fixing half the resamplers - and which said it was incomplete in the commit message - and this had somehow made it into the release I was using. One of the unfixed resamplers was the one used for VU meters in mixer apps, because that was implemented as a resampler for some reason. Also, all of this code had basically zero comments. Oh, and reverting the patch didn't even fix the crashes for me so presumably there was some other problem somewhere. Oh, and on top of that there were no stable bugfix-only releases of PulseAudio, so even if it did get fixed upstream it'd come with a bunch of new non-bugfix changes with the same level of quality and scrutiny.

> expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes.

Why would it be weird or unnecessary to expect that?

Besides; that's a nice anecdote! Thanks for sharing!

The irony is that during that same time, FreeBSD somehow offered sound working out of the box, complete with input mixing, and without anything like ALSA.

This is factually false in my case since ALSA alone has always been fine, no issues. And since I switched (with the same hardware) pipewire also works just fine. But pulseaudio (pa+alsa ofc) is just simply broken on my archlinux install.

EDIT: also when pulseaudio breaks you just do `pulseaudio --kill ; pulseaudio --start` Does this really reset the hardware/firmware? I doubt it; it's just configured poorly for my hardware why is that hard to believe?

> Does this really reset the hardware/firmware?

No, but it can release resources and that in turn can cause the driver to reset in part.

It is probably the driver that leads to have pulse audio use 10% of the CPU of a quadcore when doing nothing / not playing any media?

Also, probably the driver that regularly confuse it's inputs and outputs settings...

Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does restarting the userland sound daemon reset the drivers operating in kernel space? How would that work?

Driver issues can sometimes manifest as kernel exposed API interfaces blocking/using too much CPU in stupid ways/freezing when they should not; killing the "offending" userland program using those APIs will often end up releasing the resources acquired by invoking them.

Linux might be a monolithic kernel, but it's not like the entire kernel with all it's features/modules need to be loaded all at once.

Have never used those APIs, but I would assume it'd happen if drivers fail to implement basic API promises and PulseAudio doesn't code defensively against those kind of bugs.

If drivers fail that disastrously to implement the APIs they say they implement, how did they end up in distributors' kernel trees?

They were deemed "good enough" when all you were using was basic, simple OSS. Not when you're attempting to use all the capabilities of ALSA.

> PulseAudio doesn't code defensively against those kind of bugs.

That's a reoccurring pattern across Lennart software. He gets an idea of the way things should work, maybe from the spec or maybe just from his own subjective biases, and has his software expect things to work that way and fail when it doesn't. Every time, he'll say it's the other guys fault. Sometimes his software even fails unsafe and he still blames everybody else.

The '0day' username bug in systemd exemplifies this. Lennart decided that usernames beginning with numbers weren't valid, even though Linux permits it. Systemd was found to run service files with User=0day specified as root instead, not as the user 0day. To Lennart this was not a bug because in his subjective opinion the rest of the system was in error for permitting a username beginning with a number. Even if he were right that usernames beginning with numbers shouldn't be valid, the mere fact that they can occur is reason enough to code defensively around it. At the very least systemd could fail safe when it encounters such an 'invalid' username. But no, he thought there was nothing wrong with failing-to-root. It was everybody else's fault, of course.

https://lwn.net/Articles/727490/

https://github.com/systemd/systemd/issues/6237#issuecomment-...

Ubuntu's adoption of it was what pushed me away from Desktop Linux, after about a decade of being mainly a Linux user. Suddenly the one thing that had actually Just Worked for almost that entire decade, became unstable, unpredictable, and, to add insult to injury, ate tons of memory and processor cycles for unclear and likely unjustifiable reasons.

I’m sorry but I really can’t take any such take seriously. If you mean alsa, it may have worked (though let’s be honest, there was a painstakingly high amount of sound hardware that simply wasn’t supported well for decades, which was fixed over a similar timeline. “Linux sound bad” memes have been around way before PA became a thing), but the thing is, it is not adequate in itself for a typical desktop usecase, simple as that.

PipeWire has been increasingly beneficial to my usage of audio on Linux as time passes as well. Each update seems to fade it a little more into the background so I simply need not worry about it. Audio just does the expected thing for me these days, without fiddling or "hackery" required to make it so. It's also nice no longer having to worry about whether a particular bit of audio software is for Pulse, ALSA, or Jack. They all just work.

The only way Pulseaudio is palatable is by using the Pulseaudio sink in Jack.

I settled on alsa and dmix as the ultimate solutuon.

That works as long as you are not too concerned about latency, but it is a bit easier to set up than Jack. Though Ubuntu Studio takes most of the sting out of it.