I don't think ALSA and Pipewire fill the same niche anyway? I was under the impression ALSA was an API for directly talking to the audio devices, which would be used by Pipewire or Pulseaudio or that in-house solution ChromeOS uses, or whichever flavor of mixer.

End-user applications talking directly to ALSA will probably become more uncommon, though.

Edit: Yeah, the PipeWire FAQ confirms this https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Pipewire indeed doesn't replace ALSA, but it provides the ALSA API, allowing applications coded against the ALSA API to use pipewire.

I wonder, problems with PA emulating ALSA were AFAIK always blamed on apps abusing ALSA APIs. Does Pipewire do a better job of emulating ALSA than PA did, or does Pipewire just rely on the fixes installed to make those ALSA apps start to work OK on PA?

I'm not familiar with the details of this topic, sorry. I believe PA did (or still does) publish guidelines for a 'safe' subset of the ALSA API.

Don't know if Pipewire has published something similar, but I would guess there are corner cases in the ALSA API that wouldn't work well on top of Pipewire. E.g. the buffer rewinding, considering that Pipewire is explicitly designed around never doing that.

Ah this is very cool to hear, thanks for the clarification.

That would be great for new software, but what about older software that doesn't know about Pipewire? Can Pipewire mimick the presence of say Pulseaudio or Jack, so that one could safely uninstall them without breaking anything? As an example, I installed Pipewire and other related packages, including pipewire-pulse, then proceeded to uninstall Pulseaudio, but the package manager complained that to continue I had to uninstall also gqrx-sdr, which is a software defined radio program that requires Pulseaudio as a dependency. In other words, to have everything working, I would still have to keep all old audio systems in place anyway, a scenario that reminds me that old xkcd cartoon about standards.

It does replace Jack and Pulse Audio as it implements its APIs. If you have pulse and pipewire running in parallel they will actually conflict.

You can still have pulseaudio installed, but you can disable its daemon or socket so it doesn't actually run.

Yes as long it does not use some kind of modules. But 99% of programs can already use pipewire via the shim.