3 ms·

> I'm still baffled by how something as basic as audio output can be eternally fragile in linux Yeah, broken drivers. You see, before pulseaudio came along, a

by esarbe 4y ago

> I'm still baffled by how something as basic as audio output can be eternally fragile in linux 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.

robonerd 4y ago
Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does restarting the userland sound daemon reset the drivers operating in kernel space? How would that work?
- mixedCase 4y ago
  Have never used those APIs, but I would assume it'd happen if drivers fail to implement basic API promises and PulseAudio doesn't code defensively against those kind of bugs.
  - vintermann 4y ago
    If drivers fail that disastrously to implement the APIs they say they implement, how did they end up in distributors' kernel trees?
    - ElectricalUnion 4y ago
      They were deemed "good enough" when all you were using was basic, simple OSS. Not when you're attempting to use all the capabilities of ALSA.
  - robonerd 4y ago
    > PulseAudio doesn't code defensively against those kind of bugs. 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://lwn.net/Articles/727490/ https://github.com/systemd/systemd/issues/6237#issuecomment-311900864 https://github.com/systemd/systemd/issues/6237#issuecomment-...
- ElectricalUnion 4y ago
  Driver issues can sometimes manifest as kernel exposed API interfaces blocking/using too much CPU in stupid ways/freezing when they should not; killing the "offending" userland program using those APIs will often end up releasing the resources acquired by invoking them. 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.
int_19h 4y ago
The irony is that during that same time, FreeBSD somehow offered sound working out of the box, complete with input mixing, and without anything like ALSA.
makomk 4y ago
Enabling software audio mixing with ALSA required copying and pasting a small handful of lines into your ALSA config file and just worked. Most of PulseAudio's hardware problems were caused by it having weird and unnecessary expectations, like wanting to know the exact sample being played by the hardware or expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes. 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.
- esarbe 4y ago
  > expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes. Why would it be weird or unnecessary to expect that? Besides; that's a nice anecdote! Thanks for sharing!
greatgib 4y ago
It is probably the driver that leads to have pulse audio use 10% of the CPU of a quadcore when doing nothing / not playing any media? Also, probably the driver that regularly confuse it's inputs and outputs settings...
gnulinux 4y ago
This is factually false in my case since ALSA alone has always been fine, no issues. And since I switched (with the same hardware) pipewire also works just fine. But pulseaudio (pa+alsa ofc) is just simply broken on my archlinux install. 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?
- esarbe 4y ago
  > Does this really reset the hardware/firmware? No, but it can release resources and that in turn can cause the driver to reset in part.

by esarbe 4y ago

robonerd 4y ago

Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does restarting the userland sound daemon reset the drivers operating in kernel space? How would that work?

mixedCase 4y ago
Have never used those APIs, but I would assume it'd happen if drivers fail to implement basic API promises and PulseAudio doesn't code defensively against those kind of bugs.
- vintermann 4y ago
  If drivers fail that disastrously to implement the APIs they say they implement, how did they end up in distributors' kernel trees?
  - ElectricalUnion 4y ago
    They were deemed "good enough" when all you were using was basic, simple OSS. Not when you're attempting to use all the capabilities of ALSA.
- robonerd 4y ago
  > PulseAudio doesn't code defensively against those kind of bugs. 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://lwn.net/Articles/727490/ https://github.com/systemd/systemd/issues/6237#issuecomment-311900864 https://github.com/systemd/systemd/issues/6237#issuecomment-...
ElectricalUnion 4y ago
Driver issues can sometimes manifest as kernel exposed API interfaces blocking/using too much CPU in stupid ways/freezing when they should not; killing the "offending" userland program using those APIs will often end up releasing the resources acquired by invoking them. 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.

int_19h 4y ago

The irony is that during that same time, FreeBSD somehow offered sound working out of the box, complete with input mixing, and without anything like ALSA.

makomk 4y ago

Enabling software audio mixing with ALSA required copying and pasting a small handful of lines into your ALSA config file and just worked. Most of PulseAudio's hardware problems were caused by it having weird and unnecessary expectations, like wanting to know the exact sample being played by the hardware or expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes. 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.

esarbe 4y ago
> expecting analog volume controls to have perfectly accurate gain and glitch-free volume changes. Why would it be weird or unnecessary to expect that? Besides; that's a nice anecdote! Thanks for sharing!

greatgib 4y ago

It is probably the driver that leads to have pulse audio use 10% of the CPU of a quadcore when doing nothing / not playing any media? Also, probably the driver that regularly confuse it's inputs and outputs settings...

gnulinux 4y ago

This is factually false in my case since ALSA alone has always been fine, no issues. And since I switched (with the same hardware) pipewire also works just fine. But pulseaudio (pa+alsa ofc) is just simply broken on my archlinux install. 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?

esarbe 4y ago
> Does this really reset the hardware/firmware? No, but it can release resources and that in turn can cause the driver to reset in part.