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.
Introducing breakage, complexity and general fragility to the common case, which was previously working fine, will obviously make a whole lot of people upset.