And rightly so. There’s a reason we’re migrating away from pulse to pipewire.
For the longest time the solution to any audio issues was “just uninstall PulseAudio, and use plain ALSA”, and that usually worked. I held out for years and ran an ALSA only setup because it just worked and PulseAudio was always giving me one issue or another (audio lag, crackling, unexplained muting), until some applications started to drop ALSA support.
Then Pipewire came along, and so far it has been rock solid for me.
Both were just a pain in their own right, IMHO. My previous Focusrite interface was quite fiddly to get working with ALSA and just worked OOTB with Pulseaudio. I also don’t miss messing with ALSA/JACK at all.
Pipewire has pretty much been a drop-in replacement for me, with how it can act as a Pulseaudio backend.
Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.
ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.
And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.
ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.
That would kill your battery life.
Pulseaudio’s (terribly named) “glitch free” audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.
So, from the user’s perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.
ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.
And then firefox broke apulse again due some sandboxing permissions, and you had to override it with some about:config flag: security.sandbox.content.write_path_whitelist
So that worked for a while and then the audio in some proton games stopped working, and that’s when I said fuck it and gave up. I’m only prepared to play the whack-a-mole game for so long, and if the solution to pulseaudio flakiness becomes even more alsa related flakiness, it’s not worth it anymore.
There was a similar fuss when distros moved from alsa to pulse.
And rightly so. There’s a reason we’re migrating away from pulse to pipewire.
For the longest time the solution to any audio issues was “just uninstall PulseAudio, and use plain ALSA”, and that usually worked. I held out for years and ran an ALSA only setup because it just worked and PulseAudio was always giving me one issue or another (audio lag, crackling, unexplained muting), until some applications started to drop ALSA support.
Then Pipewire came along, and so far it has been rock solid for me.
Both were just a pain in their own right, IMHO. My previous Focusrite interface was quite fiddly to get working with ALSA and just worked OOTB with Pulseaudio. I also don’t miss messing with ALSA/JACK at all.
Pipewire has pretty much been a drop-in replacement for me, with how it can act as a Pulseaudio backend.
Possibly hardware dependent?
I always had audio hardware that was well supported by ALSA, I never had any ALSA issues until applications stopped supporting it.
Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.
ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.
And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.
ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.
That would kill your battery life.
Pulseaudio’s (terribly named) “glitch free” audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.
So, from the user’s perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.
ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.
Just run them with apulse
Yeah I did that for a while with firefox.
And then firefox broke apulse again due some sandboxing permissions, and you had to override it with some
about:configflag:security.sandbox.content.write_path_whitelistSo that worked for a while and then the audio in some proton games stopped working, and that’s when I said fuck it and gave up. I’m only prepared to play the whack-a-mole game for so long, and if the solution to pulseaudio flakiness becomes even more alsa related flakiness, it’s not worth it anymore.
ESD >> Pulse
Having been a linux user around the time of both rollouts I’ve had a way better time with pipewire. We’ve come a long way since OG pulseaudio
I seem to remember canonical rushing pulse into an LTS before it was actually ready. Not the first time they’ve done that either.