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.
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!
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.
Also, probably the driver that regularly confuse it's inputs and outputs settings...
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.
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-...
Evidently it seems to work for many people, the trouble it's caused has far outweighed any benefit (plus I know quite a few people dropped firefox for chrome when it went pulseaudio only - is that still the case?).
I do remember when PulseAudio seemed to be the source of many problems, but this was over a decade ago.
One of the big problems is that the Linux audio stack is built out of components that rely on assumptions about the next lower level of the stack that are often untrue. You might assume that your audio hardware has a volume control, assume it can perform mixing, assume it doesn't change configuration, assume there's only one user, assume (or want to assume) it has a specific sample rate, etc. PulseAudio papers over this stuff and deals with permissions, so your applications can actually work.
If you have sufficiently boring PC hardware and sufficiently boring use cases, the audio will just kind of work anyway, without PulseAudio.
Linux audio has more than its fair share of problems in the stack, but in my experience, PulseAudio is more of a solver of problems and less of a source of problems.
Separately the company I worked for ditched it as well due to the issues, to be fair though in tnat case since they only needed a single - reliable - audio output so there was no case of PA anyway.
Introducing breakage, complexity and general fragility to the common case, which was previously working fine, will obviously make a whole lot of people upset.
I had my share of hardware, and PA had problem with only one piece (a nettop with Nvidia Ion2, audio via hdmi). It turned out that the hardware couldn't really play 44,1 kHz audio, it's clock was too unreliable and resulted in drop outs. PA couldn't fix the hardware, but could resample everything to 48 kHz on CPU, and with that there was no playback problem.
So yes, it exposed problems, and it forced to fix them. We are all better off today for that.
I cannot fathom how people are able to repress the memory of how bad Linux audio was before pulseaudio.
Oh dear.. I'm not going to comment on that. I don't think it's productive.
> I never experienced any trouble with audio
I refer to stuff alsa drivers reporting wrong values[0] or cards being locked to a specific rate [1]
Before pulseaudio only one application could access the sound card. And alsa-mixer was broken half of the time. The list of defects goes on and on. Configuration relied on different settings of also that needed to be tuned for each driver separately. Getting sound to work on Linux was not a fun place to be.[2]
Pulseaudio exposed all these problems using a unified interface and forced "us" to fix these bugs.
[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/410887
[1] https://lore.kernel.org/all/1034325263.474.37.camel@diesel/T...
[2] https://www.techrepublic.com/article/configuring-linux-sound...
That's only true if the sound card has no hardware mixing support (or very limited number of streams, where it would suddenly break after a certain number of applications) _and_ the alsa setup didn't include dmix (software mixing).
Not sure what problems you had with alsamixer, for me it always worked (but maybe I never tried anything sufficiently fancy for it to break).
But I am with the previous poster on this. I have had way more problems with pulseaudio than without. Also it's not only alsa drivers that can be at fault here, but pulseaudio also consults other hardware databases which alsa does not use, which can contain mistakes that can make pulseaudio unusable (had that issue not even a month ago with an external usb sound card).
It's simple: Don't tell other people what they did or didn't experience. If you don't understand that, then you aren't worth talking to.
Get fucking real, I have better things to do with my life than waste time ingratiating myself with the likes of pusleaudio devs. "Audio stopped working" describes hundreds if not thousands of pulseaudio bugs, do you really expect frustrated end users to drop everything else going on in their life and spend weeks learning the ropes of this shit? Get real.
Are you sure you're responding to the correct post? I didn't say anything remotely like this. I asked if you would report the bug or try to do a little debugging, like spending a few minutes up to an hour. You don't have to learn any ropes, the internals should be very familiar to anyone who knows C and has some knowledge of audio. If this is important to your job, the company should be willing to let you do this on paid time. This stuff is open source, you either have a support vendor you pay to fix these bugs, or your company assigns developers to fix them yourself. There is no other way it happens. It's not a waste of time if you actually fix the bug.
And just to stress this, there is no other way the bugs get fixed. This is it. This is the whole thing. Some person somewhere does actually need to drop everything and go and start spending time fixing the bugs. No, it doesn't have to be for weeks. If you think a thousand bugs is a lot, well, yeah, it is. That's why you need to go take some initiative to give some information, to make your bug known and make it possible for anyone else to help. Otherwise, it blends in with all the other low-information bugs and it falls back on you to go fix it yourself. A bug report that just says "it doesn't work" with no additional information is not actionable, you need to provide more than that for anyone to be able to help you. If you become hostile after being asked to spend a few minutes reporting bugs, then it is definitely going to be impossible for anyone to help you.
One big problem here is that the "good path" for audio without PulseAudio applies to a shrinking segment of Linux user base.
Have fun routing audio from one stream to one device and another stream to a different device on Windows or macos!
I can do that with pulseaudio, but it's not fun.
I'm quite sure this process starts with me writing some config files on both of these computers. That's how it worked every other time I've tried these sort of things with Pulseaudio. These sort of tricks are possible for techies to do with Pulseaudio, but for the proverbial grandmother user they may as well not exist because the system as a whole certainly isn't going to make it easy.
So don't be so sure ;)
You just tick a checkbox in paprefs to enable networking (which is perfectly reasonable, as in most cases you don't want to have it enabled by default), and that's it. It finds the other PC via zeroconf and it shows up as a regular output device.
Depending on distro you use, you may need to install PulseAudio's zeroconf module and make sure Avahi is running, but a properly configured desktop distro will have all that either by default or a single package installation away these days.
I don't know about that. Talent alone doesn't make someone a good fit for a team. Would you want to work alongside Poettering? Or de Raadt?
I wouldn't, and that means I wouldn't hire them either.