pwvucontrol
pwvucontrol copied to clipboard
Support wireplumber 0.5
Arch is using wireplumber 0.5, which means that pwvucontrol, depending on 0.4, can't be built.
Blocked by open issue upstream: arcnmx/wireplumber.rs/issues/35
Yes. I will have to wait for wireplumber-rs 0.5 as well.
If you really want to you can parallel install libwireplumber 0.4 with 0.5 on the same system as long as you only copy libwireplumber.0.4.so to your distro's /usr/local/lib equivalent and skip the rest of the stuff (wpctl, wireplumber binary itself and so on). Then pwvucontrol can be built against that and still work. This is what I do on my system during development since upgrading to Fedora 40 which ships wireplumber 0.5.
It only uses libwireplumber to talk to pipewire and having that older library version has no impact on the functioning of your pipewire or wireplumber installation.
Yes. I will have to wait for wireplumber-rs 0.5 as well.
Of course! I didn't mean to imply you ought to do anything in the meantime. I'm just opening to keep track of what's going on. I have a bad memory, so I've already cloned this repo and failed to build twice.
you can parallel install libwireplumber 0.4 with 0.5
Thanks, I appreciate the tip! I don't really want to mess around with going behind my package manager's back though, I'm happy to wait.
Hi,
Sorry for the dumb question, but where can I get libwireplumber.0.4.so ?
Thanks
If you're also on arch, it's likely still in your pacman cache. You can do
ls /var/cache/pacman/pkg/|grep libwireplumber to check. Copy the latest 0.4 to an empty directory and extract it using unzstd and tar. That should give you a just usr directory containing the package contents, including the file you want under ./usr/lib
If it's not in the cache, see https://wiki.archlinux.org/title/downgrading_packages#Arch_Linux_Archive
Debian Trixie (testing) is currently at libwireplumber 0.4.13 (, or libwireplumbe-0.5). Is there any chance to downgrade to build process such as it builds with 0.4.13?
Commenting to follow this issue, and to give my vote for support of wireplumber-0.5
Same here, would love to make an AUR package but I don't think I should ship one since it requires a version below.
@ThatOneCalculator I managed to make it work. Here is my diff:
diff --git a/Cargo.toml b/Cargo.toml
index cb1c308..04c84f6 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -10,8 +10,7 @@ glib = { version = "0.18", features = ["log"] }
log = "0.4.11"
imbl = "3.0.0"
once_cell = "1.15.0"
-wireplumber = { git = "https://github.com/arcnmx/wireplumber.rs.git", rev = "2c0ee463d029d3562ee66db90554c5af573565c1", features = ["v0_4_16"] }
+wireplumber = { git = "https://github.com/arcnmx/wireplumber.rs.git", rev = "a01b47d27e3e38c050e939a0176a565a27c1aee1", features = ["v0_4_12"] }
futures = "0.3"
anyhow = "1.0"
pipewire = "0.7"
diff --git a/meson.build b/meson.build
index 066e09a..32c2f22 100644
--- a/meson.build
+++ b/meson.build
@@ -14,7 +14,7 @@ dependency('gio-2.0', version: '>= 2.66')
dependency('gtk4', version: '>= 4.0.0')
dependency('libadwaita-1', version: '>= 1.2')
dependency('libpipewire-0.3', version: '>= 0.3.83')
-dependency('wireplumber-0.4', version: '>= 0.4.15')
+dependency('wireplumber-0.4', version: '>= 0.4.13')
find_program('glib-compile-resources', required: true)
glib_compile_schemas = find_program('glib-compile-schemas', required: true)
``
@flipreverse I tried applying it directly but got error: corrupt patch at line 14
Also, even applying those changes manually, I get this:
Run-time dependency libpipewire-0.3 found: YES 1.2.1
Found CMake: /usr/bin/cmake (3.30.0)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency wireplumber-0.4 found: NO (tried pkgconfig and cmake)
meson.build:17:0: ERROR: Dependency "wireplumber-0.4" not found, tried pkgconfig and cmake
If you really want to you can parallel install libwireplumber 0.4 with 0.5 on the same system as long as you only copy libwireplumber.0.4.so to your distro's /usr/local/lib equivalent and skip the rest of the stuff (wpctl, wireplumber binary itself and so on).
Thanks for this hint. I have created a compatibility package in the AUR to provide this and also created an AUR package for pwvucontrol.
Hi here, there is already a wp 0.5 branch in the WirePlumber rs repository.
Also, even applying those changes manually, I get this:
Run-time dependency libpipewire-0.3 found: YES 1.2.1 Found CMake: /usr/bin/cmake (3.30.0) WARNING: CMake Toolchain: Failed to determine CMake compilers state Run-time dependency wireplumber-0.4 found: NO (tried pkgconfig and cmake) meson.build:17:0: ERROR: Dependency "wireplumber-0.4" not found, tried pkgconfig and cmake
Although quite late: Have you installed libwireplumber-0.4-0?
Is this the reason why pwvucontrol currently shows up as using the old API?
[1] % wpctl status
PipeWire 'pipewire-0' [1.2.5, c0rn3j@Luxuria, cookie:2703756527]
└─ Clients:
32. plasmashell [1.2.5, c0rn3j@Luxuria, pid:9997]
67. pwvucontrol [0.3.83, c0rn3j@Luxuria, pid:2]
Any news here? Is it possible to build against the wp-0.5 branch of wireplumber rs?
Any updates on this issue?
So I changed this:
-dependency('wireplumber-0.4', version: '>= 0.4.15')
+dependency('wireplumber-0.5', version: '>= 0.5.8')
And then during the build I got:
warning: [email protected]:
error: failed to run custom build command for `wireplumber-sys v0.1.0 (https://github.com/arcnmx/wireplumber.rs.git?rev=6e48383a85aecfca22dac3ffc589fb3f25404eda#6e48383a)`
Caused by:
process didn't exit successfully: `/usr/pkgmk/work/pwvucontrol/src/pwvucontrol/build/src/release/build/wireplumber-sys-6716a3c4876bdb2f/build-script-build` (exit status: 1)
--- stdout
cargo:rerun-if-env-changed=WIREPLUMBER_0.4_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
cargo:warning=
pkg-config exited with status code 1
> PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags wireplumber-0.4 'wireplumber-0.4 >= 0.4.16'
The system library `wireplumber-0.4` required by crate `wireplumber-sys` was not found.
Ah ha! That led to this issue: https://github.com/arcnmx/wireplumber.rs/issues/35 and this branch: https://github.com/arcnmx/wireplumber.rs/tree/wp-0.5
So now I got this diff:
diff --git a/Cargo.toml b/Cargo.toml
index 6c5cbea..d2f4cc0 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -18,9 +18,9 @@ pipewire = "0.8"
formatx = "0.2.3"
[dependencies.wireplumber]
-git = "https://github.com/arcnmx/wireplumber.rs.git"
-rev = "6e48383a85aecfca22dac3ffc589fb3f25404eda"
-features = ["v0_4_16"]
+git = "https://github.com/arcnmx/wireplumber.rs"
+features = ["v0_5"]
+branch = "wp-0.5"
[dependencies.adw]
package = "libadwaita"
diff --git a/meson.build b/meson.build
index 2e23efc..0212ead 100644
--- a/meson.build
+++ b/meson.build
@@ -14,7 +14,7 @@ dependency('gio-2.0', version: '>= 2.66')
dependency('gtk4', version: '>= 4.0.0')
dependency('libadwaita-1', version: '>= 1.2')
dependency('libpipewire-0.3', version: '>= 0.3.83')
-dependency('wireplumber-0.4', version: '>= 0.4.15')
+dependency('wireplumber-0.5', version: '>= 0.5.8')
find_program('glib-compile-resources', required: true)
glib_compile_schemas = find_program('glib-compile-schemas', required: true)
And the build continues, but... it's getting stuck elsewhere. 😢
The wp-0.5 branch of wireplumber-rs is not ready yet. pwvucontrol will be stuck on wireplumber-rs 0.4 for the foreseeable future unless someone steps in and completes the work on wireplumber-rs. pwvucontrol currently need anything that is in the new version and it works very well to just link against wireplumber 0.4.
The proper solution would be to rewrite pwvucontrol to not have to depend on wireplumber by reimplementing some of the object tracking code of wireplumber in rust.
There is a branch that is compiled against wireplumber-rs' wp-0.5 branch here: https://github.com/saivert/pwvucontrol/tree/wp-0.5
I hope you guys can test this and see if it breaks something.
This is a last ditch effort before we eventually have to move forward...
Announcement Regarding wireplumber-rs Dependency and the Road Ahead
As many of you know, the wireplumber-rs library (a Rust wrapper around WirePlumber) is no longer maintained. It was a hobby project and never officially supported by the PipeWire project, which has made it a long-standing issue.
Upgrading to GNOME Flatpak runtime version 49 also requires switching to the org.freedesktop.Sdk.Extension.llvm20 SDK extension. Unfortunately, this breaks the build for WirePlumber 0.4.9 due to compiler errors. The only viable path is upgrading to WirePlumber 0.5.12 (or other recent version), which is incompatible with wireplumber-rs 0.4. This effectively ends the road for wireplumber-rs.
I’m not in a position to fork and maintain wireplumber-rs myself, as I lack the expertise in gobject-introspection and writing robust Rust bindings for WirePlumber.
Possible Paths Forward
-
Rewrite
pwvucontrolto usepipewire-rsdirectlyThis means re-implementing the tracking of PipeWire objects and communication with the PipeWire server—functionality previously handled by WirePlumber. I can reuse some of Helvum’s code for this.
-
Switch to using PulseAudio APIs
PulseAudio remains supported for backward compatibility and is considered a higher-level API by the PipeWire project. There are solid Rust wrappers available. I could still use PipeWire APIs where needed, but this would mean mixing two protocols e.g., reconciling a PulseAudio sink with a PipeWire node for direct API calls. While
pwvucontrolcurrently doesn't rely heavily on PipeWire-only features, future plans include support for session manager properties (e.g.,pw-metadata -n sm-settings) and node properties (e.g.,pw-cli enum-params <sink id> PropInfo), which would require the PipeWire API. -
Rewrite it in another language
I'm not going to do that. And anything besides C is still going to require a language binding for wireplumber. Maybe this is easier with python. I don't know.
Final Thoughts
This project is, above all, a personal Rust learning exercise. Like most open source projects, development happens when I have both the time and interest. I'm not committed to maintaining it indefinitely, unless it gains more contributors and traction.
That’s all for now.
There is a branch that is compiled against wireplumber-rs' wp-0.5 branch here: https://github.com/saivert/pwvucontrol/tree/wp-0.5
I hope you guys can test this and see if it breaks something.
I tested it in LMDE7 (Debian 13) and it works. I only had to change one line in meson.build
dependency('wireplumber-0.5', version: '>= 0.5.11')
to
dependency('wireplumber-0.5', version: '>= 0.5.8')
also tested on Debian sid, thanks for your work
@Axel-Erfurt Thanks. I relaxed the version check in meson.build just now. Also fixed the Flatpak build. This in the wp-0.5 branch.
I also managed to get the Flatpak build (still against wireplumber-rs 4.0) to build with GNOME Runtime 49 now so I may do another release for that before attempting to release a Flatpak version that builds against wireplumber-rs 5.0.
Building against wireplumber-rs 5.0 is more important for distro packages. Flatpak is a contained environment.
I just catched up on what is going on in Pipewire now and Arun Raghavan is working on a pipewire-native-rs. Tom Wagner has stepped down as maintainer and there seems to be some guys willing to take over.
Hopefully this all ends well so we can keep coding pipewire stuff in rust. Fingers crossed!