This is now in the testers repository.
I can confirm pavucontrol works with pipewire an pipewire-pulse even on Wayland. Tested on Gnome, Sway and KDE.
1 Like
Wireplumber is not needed afaik.
1 Like
As said:
Feel free to test other package combinations and report any (non-) differences.
1 Like
Bug. PipeWire maybe not ready for prime time:
Pipewire in bookworm is quite old, with known bugs. But it works most of the time and is default in debian-12 in R4.2 already.
To switch, there need to be pipewire-qubes package installed and also pipewire-pulse (which is recommended by the former). That said, I had mixed results as for automatic switch by just adjusting dependencies. Sometimes manual action was necessary to force the switch (some of those pipewire packages conflict with pulseaudio ones).
2 Likes
Now in the testers repository.
The following packages will be REMOVED:
pulseaudio-qubes
The following NEW packages will be installed:
dbus-user-session liblua5.3-0 libpipewire-0.3-0 libpipewire-0.3-common
libpipewire-0.3-modules libspa-0.2-modules libwireplumber-0.4-0 pipewire
pipewire-bin pipewire-pulse pipewire-qubes rtkit wireplumber
The following packages will be upgraded:
qubes-whonix qubes-whonix-shared-packages-recommended
qubes-whonix-workstation-packages-recommended
3 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
Need to get 2,661 kB of archives.
After this operation, 11.4 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Audio in Tor Browser on YouTube working.
1 Like
Optional, manual legacy package removal…
sudo apt purge pulseaudio*
The following packages will be REMOVED:
pulseaudio* pulseaudio-qubes* pulseaudio-utils*
sudo apt autoremove
The following packages will be REMOVED:
libfftw3-single3 libpulsedsp
Let’s see which packages remain…
dpkg -l | grep pulse
ii libpulse0:amd64 16.1+dfsg1-2+b1 amd64 PulseAudio client libraries
A dependency of other packages, just a library, is ok.
ii pipewire-pulse 0.3.65-3+deb12u1 amd64 PipeWire PulseAudio daemon
PulseAudio compatibility layer provided by PipeWire, also ok.
Audio in Tor Browser on YouTube still working. Seems all fine.
1 Like
This is now in the stable repository.
1 Like
This is now in the testers repository.
1 Like
There is a small problem with this change: pipewire-qubes only Recommends: pipewire-pulse, which technically is correct (one can have a system with just pipewire and no pulseaudio). But such system is not very useful in practice - most applications connect to pulseaudio (either real one, or pipewire-pulse). And since Whonix packages are installed with --no-install-recommends, pipewire-pulse isn’t installed in the end.
So, I’d recommend adding pipewire-pulse to the list in qubes-whonix-workstation-packages-recommended too.
2 Likes
Thank you!
Done.
1 Like
The upgrade isn’t clean… When updating a template that had pulseaudio (and pulseaudio-qubes) installed, apt dist-upgrade skips updating qubes-whonix-workstation-packages-recommended, I assume because that requires removing pulseaudio-qubes. But when doing explicit apt install qubes-whonix-workstation-packages-recommended, it does offer an update and removal of pulseaudio-qubes.
Honestly, I’m not sure how to handle this situation best. TBH, I’m not sure why it wasn’t an issue in release upgrade R4.1 → R4.2. We did need explicit pulseaudio-pipewire step in the upgrade tool for Fedora templates, but not for Debian. Maybe it’s due to which package has those dependencies (pipewire-qubes has Conflicts: pulseaudio-qubes and Recommends: pipewire-pulse - so, it’s the same package pulling one and removing the other, while on Whonix, due to --no-install-recommends it’s a different package pulling in pipewire-pulse than removing pulseaudio-qubes). I don’t fully understand this, could be something else. One thing to try might be adding Conflicts: pulseaudio-qubes to qubes-whonix-workstation-packages-recommended, but see below.
And to make things worse, pipewire-qubes isn’t a thing on R4.1 yet, which leads to another dependency issue… This issue is relevant only for a little less than 3 months (until R4.1 EOL), but still.
Maybe, for the time being, the better approach would be a less strict migration, like Depends: pipewire-qubes | pulseaudio-qubes, so it would choose pipewire for new builds, but not switch to it if pulseaudio is already installed? But in that case, I’m not sure what to do about pipewire-pulse requirement, does Debian support grouping in dependencies like Depends: (pipewire-qubes, pipewire-pulse) | pulseaudio-qubes ? If not, I guess it can be written as Depends: pipewire-qubes | pulseaudio-qubes, pipewire-pulse | pulseaudio-qubes. As for the conflict with pulseaudio, I’m not sure how to do it. Adding Conflicts: pulseaudio-qubes will break audio on R4.1. Maybe some Conflicts: pulseaudio-qubes | pipewire-qubes would work? Probably not…
The underlying issue with this migration is that pipewire and pulseaudio cannot run at the same time - there can be only one audio daemon connecting to dom0 (or other audiovm). Currently it’s achieved with package conflict. Maybe a more robust solution would be to avoid package conflict and add some runtime detection (if pulseaudio-qubes detects pipewire installed/enabled, it will not start)?
Any preference?
I do have R4.1 and R4.2 test systems, with Whonix Workstation 17 template from before this change, so I can test various options, for example if you upload some package to try to some repository (developers one?).
1 Like
This is probably good. As far as I know, the first named package in the line pipewire-qubes gets preferred, if available.
Right. I guess it won’t switch automatically then.
Hard to speak with certainty about these things. Not really well documented anywhere.
What makes this hard is that package upgrades are hard to test. I am not aware of any way to simulate this without actually attempting such upgrades. We’re kinda doing a learning by doing / reverse engineering / tinkering based approach.
No, I don’t think so. From all the debian/control files I looked at during my lifetime, I don’t remember seeing something like that. There are versioned Depends: but that looks difficult, speak error-prone. One solution might be to create a meta package qubes-audio-support-pipewire to avoid the non-existing grouping syntax support.
But a simpler solution perhaps…
pipewire-qubes | pulseaudio-qubes,
pipewire-pulse | pulseaudio-qubes,
Meaning:
- If pipewire-qubes is available, prefer it. Otherwise fall back to pulseaudio-qubes.
- If pipewire-pulse is available, prefer it. Otherwise fall back to pulseaudio-qubes.
- The fact that
pulseaudio-qubesis mentioned twice as a dependency shouldn’t cause any issues.
I am not sure but that sounds like a higher likelihood of introducing regressions. Happy to avoid if we can avoid it at the meta package level.
This is now in the developers repository.
Please let me know if that looks good enough and is functional.
Looks to work good:
- R4.1: update is clean, pulseaudio-qubes remain installed
- R4.2 that still has pulseaudio-qubes: update is clean, pulseaudio-qubes remain installed
- R4.2 that has pipewire-qubes installed already: update is clean, pipewire-pulse is pulled in too
And then, if one would like to migrate:
R4.2 that still has pulseaudio-qubes: apt install pipewire-qubes pulls in pipewire-pulse too, and removes pulseaudio-qubes
1 Like
Excellent. So that’s resolved. 
1 Like
I see this update is still only in the developers repository. Is it time to push it to testers or maybe stable?
1 Like
Done.