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.