How can Pipewire override ALSA?

With pipewire-alsa Pipewire support applications that use ALSA directly and I can’t understand that.
ALSA is an sub-system of Linux kernel, part of the kernel, so applications use syscalls to communicate with ALSA. How can pipewire-alsa interfere to this? How userland process can interfere to syscalls by another process?

And if this is possible with ALSA, why can’t Pipewire do the same with V4L sub-system of the kernel?

Before I go further an important thing to be aware of here is that unlike on ALSA, where PipeWire can provide a virtual ALSA device to provide backwards compatibility with older applications using the ALSA API directly, there is no such option possible for v4l2


Because ALSA configuration allows creating virtual sound devices and pipewire is behind the virtual device as I understand it.

No such virtual device API exists for V4L.

Are you sure?
What’s like virtual audio devices? I mean, Pipewire can show many details and control many things of them.

Then, would it be easy to add support for it? In audio side keeping backwards compatibility has been really important for Pipewire.

Thanks for answers! :slight_smile:

Reasonably sure. See /etc/alsa/conf.d/50-pipewire.conf that is defining the virtual device.

Easy, no. Needed maybe not.
If the app is using gstreamer then that has the backward compat I think already.
So a virtual v4l is not needed as far as I am aware.

Are your questsion theoretical or is there an app that is not working?

I can see now :slight_smile: Thank you again!

Do you know answer for this:

Purely theoretical. I’ve been studying about Pipewire for the last few days and I’m really interested in how it works and these questions came my mind.