Which USE flags make sense for pipewire

[pablo_supertux]

Hi

on my debian notebook for my work I recently made an upgrade from debian 11 -> 13 and was forced to use pipewire. As it so far everything has been working well, I thought about migrating to pipewire as well, specially since pipewire has been made default in the desktop profiles. For now, I'm still keeping a openrc pulseaudio-only system.

I see that pipewire has quite a few USE flags and equery uses media-video/pipewire shows me the list of use flags. Only a few are selected by default, but there a a lot of USE flags that I really don't understand why they are there, and the description is not helpful either. I opened the wiki on pipewire https://wiki.gentoo.org/wiki/PipeWire hoping that find a more detailed explanation but essentially all I got was the same output as equery.

For example, there is the USE flag echo-cancel with the description "Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing". But what does that mean? And is it something that I need/want? I kind of have an idea what it does, but I'm not sure. Then there are the USE flags ffmpeg and fftw. What happens if there remain disabled?

And what about pipewire-alsa? Is this really needed when "sound-server" is enabled and pipewire works as a pulseaudio server? Would I need that? And the same for gstreamer. Why would I need that?

So, which are the most common USE flags that should be enabled?

[sam_]

For example, there is the USE flag echo-cancel with the description "Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing". But what does that mean? And is it something that I need/want? I kind of have an idea what it does, but I'm not sure. Then there are the USE flags ffmpeg and fftw. What happens if there remain disabled?

And what about pipewire-alsa? Is this really needed when "sound-server" is enabled and pipewire works as a pulseaudio server? Would I need that? And the same for gstreamer. Why would I need that?

pipewire-alsa is a plugin for pipewire to drop into alsa so that alsa-only clients can speak to it. It's not on by default (so no, not really needed indeed, at least right now). It would be needed if you don't have any puleaudio daemon running (pipewire or otherwise) and no alsa-plugins[pulseaudio].

The others are misc. flags for some tools that pipewire installs or for filters you can configure.

So, which are the most common USE flags that should be enabled?

The defaults

[szatox]

This is my setup. Some flags are deliberate, some inherited. Like, jack-sdk accepts JACK clients, while ssl and zeroconf are examples of stuff enabled globally even though there is nothing in a desktop's sound system that actually needs them.

Code: Select all

media-video/pipewire-1.4.9-r2::gentoo was built with the following:
USE="X bluetooth dbus elogind extra ffmpeg gsettings jack-sdk liblc3 lv2 modemmanager readline sound-server ssl v4l zeroconf -doc -echo-cancel -fftw -flatpak -gstreamer -ieee1394 -jack-client -libcamera -loudness -man -pipewire-alsa -roc (-selinux) (-system-service) (-systemd) -test"

For example, there is the USE flag echo-cancel with the description "Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing". But what does that mean? And is it something that I need/want? I kind of have an idea what it does, but I'm not sure. Then there are the USE flags ffmpeg and fftw. What happens if there remain disabled?

I don't really know, but I can make a guess. Pipewire supports audio filters and I think i has some interface to DSP. I suppose those flags are related to this functionality where you define audio effects in pipewire's configuration and they get applied automagically whenever your audio stream hits a particular node (e.g. the default sink).
Honestly, just use easyeffects instead, unless you have a good reason to do it the hard way.

And what about pipewire-alsa? Is this really needed when "sound-server" is enabled and pipewire works as a pulseaudio server?

It makes pipewire act as a virtual audio device. You're getting an extra "master" volume knob, and I think it also links in pipewire bridging for alsa-only applications.
Do you need it... Not really, as long as you link the config in /etc/alsa/conf.d
50-pipewire.conf -> /usr/share/alsa/alsa.conf.d/50-pipewire.conf
Mind that pulseaudio interface adds latency and coplicates setup, as it's done via a proxy daemon. JACK and ALSA protocols are supported by the pipewire daemon directly.
It might be necessary to have at least one of alsa/jack/pa enabled though.

As a side note, pipewire takes a bit of a funny approach to dealing with multitude of inputs/outputs on modern systems. I recommend installing wiremix right away, before you need it (and realize you don't know what you're missing)

[pablo_supertux]

@sam thanks for the explanation

@szatox so, you would recommend for alsa-only applications to bypass the pulseaudio interface use pipewire directly? In that case setting pipewire-alsa is a good idea?

It might be necessary to have at least one of alsa/jack/pa enabled though.

I don't understand what you mean. USE flags for pipewire? As far as I can see there is no USE flag directly for enabling/disabling pulseaudio in pipewire. Or is this backed in when "sound-server" is selected? And why would anyone want to install pipewire without the sound-server flag?

[szatox]

Yes, I meant use flags, and you're right there is no flag for PA; there is pipewire-pulse daemon which you can chose to start or not.
Unfortunately I haven't fully figured out relations between interfaces yet, I'll probably do it in a few days, installing a new machine.
If you like pulseaudio, you can keep using its tools with pipewire's compatibility layer, but pretty much everything supports ALSA protocol, so went with it for lower complexity. I know for sure pipewire-alsa is not _necessary_ for alsa support: I don't have it because I didn't like the virtual audio device obscuring my view, you may have a different opinion on it.
You absolutely do need the link to pipewire's config file in alsa/conf.d I mentioned before.

About that sound-server flag, pipewire can be used for routing video too. I know it's used e.g. for screen capture on wayland.
It is actually still possible to use pure ALSA for sound. This said, it really is nice to hear the quite parts loud and clear, and not have my ears blown off a second later, and fixing audio on the fly is much easier done with a sound server than without it. Live noise and echo removal options are quite handy too.

[pablo_supertux]

@szatox thanks

[Goverp]

... For example, there is the USE flag echo-cancel with the description "Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing". But what does that mean? And is it something that I need/want? I kind of have an idea what it does, but I'm not sure. Then there are the USE flags ffmpeg and fftw. What happens if there remain disabled? ...

FWIW, the echo canceller is exceedingly useful if you're a Zoom user with external speakers rather than headphones. It filters PC/webcam sound input to remove any output sent to the speakers - otherwise you get echos and/or feedback loops from the PC listening to itself. AFAIR you just need it installed - Zoom then takes care of using it. It probably gets used by other web-based conferencing tools.

[logrusx]

For example, there is the USE flag echo-cancel with the description "Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing". But what does that mean? And is it something that I need/want? I kind of have an idea what it does, but I'm not sure.

I enabled this when I was trying to make my laptop handle calls from my phone connected through bluetooth but it didn't work well for me. I needed it to cancel the echo that was happening through the integrated microphone and speakers. I also remember it wasn't a trivial setup. I had to configure sinks and sources and stuff and I didn't like the end result. It was not possible to do what I wanted.

FWIW, the echo canceller is exceedingly useful if you're a Zoom user with external speakers rather than headphones.

Not really.

It filters PC/webcam sound input to remove any output sent to the speakers - otherwise you get echos and/or feedback loops from the PC listening to itself.

It doesn't do a good job.

AFAIR you just need it installed - Zoom then takes care of using it.

Not really. AFAIR Zoom handled this by itself. And it's not just being installed. You need to configure sinks and sources and configure them as default devices for it to work, so you most probably got the impression Zoom was using it when it fact it's PW which has to use it.

Best Regards,
Georgi

[szatox]

About that zoom-call echo, that's yet another case for "just use easyeffects".
It has echo canceller plugin. Haven't used it, but I see it hooks into both, mic and speakers outputs, so it should actually be able to almost completely suppress the feedback.

Also, don't use zoom. They got caught server-side recording confidential conferences of their customers... A bunch of times.
How did they get caught? Recordings leaked.

[Goverp]

... Not really. AFAIR Zoom handled this by itself. And it's not just being installed. You need to configure sinks and sources and configure them as default devices for it to work, so you most probably got the impression Zoom was using it when it fact it's PW which has to use it. ...

My mileage may vary. I got echoes until I installed the echo canceller, as recommended when I searched the Internet at the time. And AFAIR no configuration needed.

[b11n]

Also, don't use zoom. They got caught server-side recording confidential conferences of their customers... A bunch of times.
How did they get caught? Recordings leaked.

That's not quite true, is it?