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-...
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.