Pipewire is implementing Alsa, Pulse Audio and Jack already.
I don't think alsa is going away but I can see Pulse Audio and Jack being replaced by it quite quickly.
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.
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.
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.
