8 ms·

I've been using linux for decades and by far -- by a HUGE margin -- PulseAudio has been the most annoying and broken thing I had to use. I'm still baffled by ho

I've been using linux for decades and by far -- by a HUGE margin -- PulseAudio has been the most annoying and broken thing I had to use. I'm still baffled by how something as basic as audio output can be eternally fragile in linux! And before you say you might have quirky hardware: my daily laptop is a Lenovo X1 Carbon 7th gen. 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.

corrral 4y ago
Ubuntu's adoption of it was what pushed me away from Desktop Linux, after about a decade of being mainly a Linux user. Suddenly the one thing that had actually Just Worked for almost that entire decade, became unstable, unpredictable, and, to add insult to injury, ate tons of memory and processor cycles for unclear and likely unjustifiable reasons.
- kaba0 4y ago
  I’m sorry but I really can’t take any such take seriously. If you mean alsa, it may have worked (though let’s be honest, there was a painstakingly high amount of sound hardware that simply wasn’t supported well for decades, which was fixed over a similar timeline. “Linux sound bad” memes have been around way before PA became a thing), but the thing is, it is not adequate in itself for a typical desktop usecase, simple as that.
jacquesm 4y ago
The only way Pulseaudio is palatable is by using the Pulseaudio sink in Jack.
- sam_lowry_ 4y ago
  I settled on alsa and dmix as the ultimate solutuon.
  - jacquesm 4y ago
    That works as long as you are not too concerned about latency, but it is a bit easier to set up than Jack. Though Ubuntu Studio takes most of the sting out of it.
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
zerocrates 4y ago
I'm also using and happy with Pipewire but I can't remember the last time I had a PulseAudio issue, across many systems. 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.
- deathanatos 4y ago
  Yeah, same; I can't help but think there is a vocal minority in these threads that thinks Pulse is broken. 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.
blooalien 4y ago
PipeWire has been increasingly beneficial to my usage of audio on Linux as time passes as well. Each update seems to fade it a little more into the background so I simply need not worry about it. Audio just does the expected thing for me these days, without fiddling or "hackery" required to make it so. It's also nice no longer having to worry about whether a particular bit of audio software is for Pulse, ALSA, or Jack. They all just work.

corrral 4y ago

Ubuntu's adoption of it was what pushed me away from Desktop Linux, after about a decade of being mainly a Linux user. Suddenly the one thing that had actually Just Worked for almost that entire decade, became unstable, unpredictable, and, to add insult to injury, ate tons of memory and processor cycles for unclear and likely unjustifiable reasons.

kaba0 4y ago
I’m sorry but I really can’t take any such take seriously. If you mean alsa, it may have worked (though let’s be honest, there was a painstakingly high amount of sound hardware that simply wasn’t supported well for decades, which was fixed over a similar timeline. “Linux sound bad” memes have been around way before PA became a thing), but the thing is, it is not adequate in itself for a typical desktop usecase, simple as that.

jacquesm 4y ago

The only way Pulseaudio is palatable is by using the Pulseaudio sink in Jack.

sam_lowry_ 4y ago
I settled on alsa and dmix as the ultimate solutuon.
- jacquesm 4y ago
  That works as long as you are not too concerned about latency, but it is a bit easier to set up than Jack. Though Ubuntu Studio takes most of the sting out of it.

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

zerocrates 4y ago

I'm also using and happy with Pipewire but I can't remember the last time I had a PulseAudio issue, across many systems. 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.

deathanatos 4y ago
Yeah, same; I can't help but think there is a vocal minority in these threads that thinks Pulse is broken. 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.

blooalien 4y ago

PipeWire has been increasingly beneficial to my usage of audio on Linux as time passes as well. Each update seems to fade it a little more into the background so I simply need not worry about it. Audio just does the expected thing for me these days, without fiddling or "hackery" required to make it so. It's also nice no longer having to worry about whether a particular bit of audio software is for Pulse, ALSA, or Jack. They all just work.