5 ms·
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
by spijdar 5y ago
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#does-pipewire-replace-alsa https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
- jabl 5y agoPipewire indeed doesn't replace ALSA, but it provides the ALSA API, allowing applications coded against the ALSA API to use pipewire.
- eredengrin 5y agoAh this is very cool to hear, thanks for the clarification.
- ncmncm 5y agoI 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?
- jabl 5y agoI'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.