Is there a reason for an App to use the pipewire API over ALSA?

Question

I've written an audio library with basic playback on ALSA & PipeWire. But I'm unsure if there is a reason to include the PipeWire option. I have PipeWire installed on my system because its nice as a user.

But from the point of view of an application doing audio playback, is there any reason to use PipeWire instead of ALSA? I think there must be since SDL goes thru the trouble of supporting ALSA, PipeWire, PulseAudio, etc.

Is it because the PipeWire API is faster than pipewire-alsa for those that use PipeWire? Or is there something else I'm unaware of?

Answer 1

pipewire is a higher lever tool than ALSA. When ALSA provides direct access right to the sound devices, Pipewire manages the connections between them and provides a higher level entry points to the same set of devices.

As the name says, pipewire wires the PIPES, which in the case of sound contain audio streams - it's a sound server. With pipewire your app will have it easier to output or input to multiple sound devices, and pipewire will do the mixing of the signals for you (or you can instruct it explicitly what to do thanks to the pipewire plugins or filter chains).

Pipewire should also provide a rather low latency (compared to raw ALSA) - it's made both for audio professionals and the casual users. And lastly, ALSA is cumbersome to use, the library is barely documented, pipewire being more modern should come with a better set of examples and more responsive community.

If you do not know the target sound device that your app will work with then pipewire is the better choice. On the other hand if the app is meant for a specific hardware, then direct connection to ALSA makes more sens, certainly providing the lowest latency and most flexibility.