Pulseeffects: [Feature Request] Adding support to Pipewire?
See https://pipewire.org
Thanks!
q2dg
All 27 comments
Once it becomes the default in Arch Linux I will definitely try to make PulseEffects working on it. But I wonder if it will be possible. Last time I looked it seemed to me that the audio section of pipewire was still in its infancy. It is not clear to me how pipewire intends to deal with audio effects tools like PulseEffects. They have to provide means for us to intercept applications audio. I hope they implement this better than pulseaudio.
wwmm
on 29 Dec 2018
@q2dg Fedora fiddlesticks will never become default in Arch Linux.
baerbock
on 30 Dec 2018
One question; what do you mean by "the default in Arch Linux"? A major point of Arch Linux is that there are almost no defaults. You install the base package group upon first install, but then you can do whatever you want.
You can for example install the pulseaudio package, or not. It might be hard to avoid, since Arch Linux is mainly a binary distribution and many packages depend on it, but still.
AsavarTzeth
on 23 Feb 2019
You can do almost anything you want. Fair enough. But as soon as you install any desktop over the base install the audio server installed as dependency is Pulseaudio and not Pipewire. It doesn't ask you which one you want. It installs Pulseaudio. And for a good reason. Some programs like Firefox expect Pulseaudio and not Pipewire to be there and as far as I understood Pipewire still needs Pulseaudio for sound and Jack for low latency. It does not play audio on its own.
wwmm
on 23 Feb 2019
It seems that they have some work on the audio side done https://github.com/PipeWire/pipewire/search?l=C&q=audio
wwmm
on 23 Feb 2019
They probably still needs some compatibility layer for Pulseaudio only apps.
I took a look at their api and I could not see a way to replicate what I can do now in Pulseaudio. Things like redirecting apps audio to a custom sink, getting info about the apps playing(sampling rate, format,...), etc
wwmm
on 23 Feb 2019
The good thing is that as GStreamer is a first class citizen for Pipewire I doubt we would need any change to the effects chain.
wwmm
on 23 Feb 2019
Okay I completely trust your judgment on whether it is ready for your use cases. I just found that specific statement odd.
I did check my system by the way. It has both pulseaudio and pipewire installed and it does have a pipewire.socket unit that is listening by default. That is in my opinion as default as it gets.
user@host ~> systemctl --user list-unit-files | grep pipewire
pipewire.service disabled
pipewire.socket enabled
user@host ~> systemctl --user status pipewire.socket
● pipewire.socket - Multimedia System
Loaded: loaded (/usr/lib/systemd/user/pipewire.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-02-23 07:43:38 CET; 8h ago
Listen: /run/user/1000/pipewire-0 (Stream)
CGroup: /user.slice/user-1000.slice/[email protected]/pipewire.socket
Also I'm quite sure that Pipewire does not currently replace the sound server component. It still uses PulseAudio for this, or so I have read. That is why both can be installed at the same time.
AsavarTzeth
on 23 Feb 2019
At some point mutter and gnome-remote-desktop started to require pipewire as a dependency. I think this was the moment it was installed in my pc.
There is a interesting read here https://github.com/PipeWire/pipewire/wiki/PulseAudio and here https://github.com/PipeWire/pipewire/wiki/FAQ But it is not clear if this is still the current state
wwmm
on 23 Feb 2019
Its been about a year and a half and I was just wondering if there was an update to this?
Note to readers, the above wiki has moved from github to gitlab, now see: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ and https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/PulseAudio
zipy124
on 10 Sep 2020
Hello! There is no work being done in the Pipewire integration. Honestly it is not clear to me yet if it is even possible to do what we need in Pipewire. I will explain in a few words how PulseEffects applies effects. Maybe it will help a reader more familiar with Pipewire to tell if it evolved enough to our needs.
One of the first steps done now is creating a virtual output device. Or a null sink in Pulseaudio's words. In order to apply effects we move the audio app from the sound card to this virtual output device. The next step is telling GStreamer to get audio from this virtual output device. After the desired effects are applied by GStreamer we tell it to play the result to the sound card.
It is still unclear to me if third party apps have a way to redirect a given audio app sound to some kind of virtual device. Another important point is that different audio contents may have different sampling rate. So this virtual device has to choose a rate and resampling anything that is different. Pulseaudio does that for us. I do not know how Pipewire is handling this.
In my opinion we will have to wait till many audio applications start to use Pipewire directly. Then the answers to these questions might become clear. At this moment I do not see a point in using Pipewire api when audio applications are still talking directly to Pulseaudio.
wwmm
on 11 Sep 2020
Today Arch Linux decided to replace Pulseaudio by Pipewire. I will save the time of PulseEffects users and say that PulseEffects is not working in Pipewire. Although Pipewire is a drop-in Pulseaudio replacement for most audio applications this only happens if the application does not need to load Pulseaudio modules. And at this moment PulseEffects relies on Pulseaudio null sinks to redirect applications. I am reading Pipewire API but so far I did not see how Pipewire intends to handle this task. And that doc is even more confusing than the one from Pulseaudio...
Long story short people replacing Pulseaudio by Pipewire may stay without PulseEffects for a while...
wwmm
on 3 Dec 2020
Can you please pin this issue?
And please @wwmm, write that statement also in the readme.
Digitalone1
on 3 Dec 2020
Can you please pin this issue?
Done.
wwmm
on 3 Dec 2020
@wwmm Work in Pipewire to support module loading (e.g. via pactl load-module, and especially the null sink) started a month ago and work is ongoing.
I would suggest filing a bug on the Pipewire issue tracker for use cases that aren't working yet.
Edit: Of course to use this you must have the pipewire-pulse daemon running.
And to users I should point out that Pipewire allows using JACK applications and Pulse applications in the same graph. This means that you could use pro-audio effects plugins in a host such as JACK Rack, Carla, or Ardour and graphical routing via a patch bay like Patchmatrix or gjackctl.
bmwalters
on 4 Dec 2020
And to users I should point out that Pipewire allows using JACK applications and Pulse applications in the same graph. This means that you could use pro-audio effects plugins in a host such as JACK Rack, Carla, or Ardour and graphical routing via a patch bay like Patchmatrix or gjackctl.
This is nice but, I think it's not really the same.
Probably I will be able to set up things on Pipewire to get the same plugins I'm using now on PulseEffects to work and play on my speakers.
Anyway PulseEffects best part is to configure easily audio effect without the need to know anything about calf, lsp, ladspa, lv2, pulseaudio and jack. Everything is in a graphical environment where every plugin has a nice and user friendly interface. And if I need to use a configuration made by another user, I can do it faster just loading its preset file.
So Pipewire is surely a good multimedia module to improve Linux system, but PulseEffects is still needed.
Digitalone1
on 4 Dec 2020
Work in Pipewire to support module loading (e.g. via pactl load-module, and especially the null sink) started a month ago and work is ongoing.
This is good. The lack of module loading support is probably the only reason why Pipewire compatibility layer is not being enough to run PulseEffects right now. In any case I have already made my mind about using Pipewire native API instead of relying on the compatibility layer. Yesterday I created a new branch where I am replacing Pulseaudio API by the one from Pipewire https://github.com/wwmm/pulseeffects/tree/pipewire. But this is going to take much more time than I initially thought. The native PIpewire API is completely different.
@Digitalone1 for some reason Arch Linux is not forcing pipewire-pulse to be installed anymore. Maybe because I have installed and uninstalled it a few times since I started the port. Who knows...
wwmm
on 4 Dec 2020
@Digitalone1 for some reason Arch Linux is not forcing
pipewire-pulseto be installed anymore. Maybe because I have installed and uninstalled it a few times since I started the port. Who knows...
I can't update if I don't install pipewire-pulse. Maybe I just need to install and uninstall it to reinstall pulseaudio?
Digitalone1
on 4 Dec 2020
I confirm that after installing pipewire-pulse, you can reinstall pulseaudio and pulseaudio-bluetooth, removing pipewire-pulse.
Digitalone1
on 4 Dec 2020
@wwmm I'm glad the porting to Pipewire is going forward.
Which are your plans for the project? Since it is interacting with Pipewire, I suppose "PulseEffects" will not be a suitable name for the application. Will you change it?
And what will it be about the old PulseEffects? I suppose it will be still adopted by other distributions that are not using Pipewire yet.
Digitalone1
on 17 Dec 2020
Will you change it?
No. I thought about this when I started the port and it is not worth it. What will need change are statements like Audio effects for Pulseaudio applications. The name can stay PulseEffects.
And what will it be about the old PulseEffects?
I definitely do not have time to develop 2 PulseEffects. Once the PipeWire branch is ready it will be moved to master and a legacy branch will be created with the current code targeting Pulseaudio. But I have no intention to work on it after moving to PipeWire. Maybe a bugfix for some issue that is really serious. But nothing more.
wwmm
on 18 Dec 2020
@wwmm Okay, so after the next 4.8.4 release that will fix issues related to locale and equalizer plugin, I recommend to make a copy of the master branch into a new legacy branch.
Maybe new release for Pipewire could be 5.0.0 and eventually bug fixes to the old legacy version in the future could be backported into 4.8.4.1.
Digitalone1
on 18 Dec 2020
The code in our PipeWire branch is almost fully functional
Effects can be applied both for the input and output of streams. Automatic usage of the current default device selected by the user should also be working. User's custom blocklist might be working too. I did not test it yet. Automatic preset loading still needs more work.
At some point in this week I will create a legacy Pulseaudio branch and move the code in PipeWire branch to the master.
wwmm
on 20 Dec 2020
The avoid-resampling feature won't work. This part of PulseEffects code has already been ported. But as can be seen here https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/472 PipeWire devices still have their sampling rate locked to the default rate set in PipeWire configuration file. 48 kHz is the default value.
wwmm
on 20 Dec 2020
@wwmm you forgot to release the 4.8.4 version with the latest fixes.
I decided to not switch to Pipewire at the moment and remain on Pulseaudio, so I will use the legacy version. The project is very promising and with high potential, but It's also not mature yet and too soon to adopt it in my opinion. I think it's like Wayland in its first years. I started to use it only in the last months and only because I switched to Gnome.
I'm not able to maintain the code related to the audio server, but since it is stable I think to be able to backport at least future new plugins and severe bugfixes made to the master branch.
If I'll manage to do it, I'll update my repository and find a way to push inside the legacy branch.
Digitalone1
on 21 Dec 2020
you forgot to release the 4.8.4 version with the latest fixes.
Done.
The project is very promising and with high potential, but It's also not mature yet and too soon to adopt it in my opinion
It is young. But I have to say my impressions about PipeWire have changed since I started the port. I was expecting it to be really far behind Pulseaudio in the audio department but from a developer point of view is actually quite close. And with an API that is more comfortable to work with. I have been using it daily and so far only minor issues. But I am not using bluetooth devices.
This is the legacy Pulseaudio branch https://github.com/wwmm/pulseeffects/tree/pulseaudio-legacy. Master is now on PipeWire.
wwmm
on 21 Dec 2020
Related issues
zedeus
·
7Comments
Ygarr
·
6Comments
alexbramford
·
4Comments
Mlocik97-issues
·
5Comments
Mlocik97
·
5Comments
Most helpful comment
Done.
It is young. But I have to say my impressions about PipeWire have changed since I started the port. I was expecting it to be really far behind Pulseaudio in the audio department but from a developer point of view is actually quite close. And with an API that is more comfortable to work with. I have been using it daily and so far only minor issues. But I am not using bluetooth devices.
This is the legacy Pulseaudio branch https://github.com/wwmm/pulseeffects/tree/pulseaudio-legacy. Master is now on PipeWire.