Now (since 2021) I use PipeWire and tbh do not know to what extent pulseaudio codebase is still utilized in my system but it all just works now.
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.
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.
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.
(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.)
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.
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-...
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.
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.
Why would it be weird or unnecessary to expect that?
Besides; that's a nice anecdote! Thanks for sharing!
Also, probably the driver that regularly confuse it's inputs and outputs settings...
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?
No, but it can release resources and that in turn can cause the driver to reset in part.