How can Pipewire override ALSA?

Ask Fedora
, ,
1

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

from: https://web.archive.org/web/20230321023555/https://blogs.gnome.org/uraeus/2021/10/01/pipewire-and-fixing-the-linux-video-capture-stack/

2

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.

3

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:

4

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?

5

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.

6

To confirm, pipewire-alsa replaces the standard ALSA library by providing a subset of what ALSA otherwise would, for applications that require it?

Exposing an ALSA API appears to be necessary, regardless of what package provides it:

7

I can see from your posts that discussions about PipeWire are still active. This thread originally addressed an initial question about how PipeWire overrides ALSA (for clarity, “PipeWire builds on top of ALSA”), which has since been resolved. If you would like to discuss specific issues, advanced features, or new misunderstandings related to PipeWire, why not start a new thread to engage in more in-depth conversations with a wider audience? There are certainly many people who would be interested.

to TL4, could this post be closed?

8

@hankuoffroad, I didn’t comment because of any other thread that I’ve posted:

  1. I’m interested in a clarification of the premise and discussion topic of this thread, which is the extent to which pipewire can replace that which usually exposes a way to interact with ALSA.

  2. I believe that my citations provide some on-topic corroborations.

9

The original thread title itself is ‘How can PipeWire override ALSA?’ This question already implies the premise that PipeWire is ‘superior to’ or ‘disables’ ALSA.

It would be much more accurate and less confusing to discuss this after clearly distinguishing between the kernel API (driver) part and the userspace library and utility part of ALSA.

Since the questioner and responder have already marked this as resolved, please understand that continuing the conversation as a linked topic is the recommended practice on the Discourse platform. Can you do that? It’s a minor point, but it’s hard to ignore the friendly reminder (“This topic has a solution already”) when replying to a resolved thread.

image

1 Like