qubes-issues
qubes-issues copied to clipboard
QubesOS
Audio doesn't work out of the box in Debian bookworm and Ubuntu jammy template
Qubes OS release
R4.2
Brief summary
Ubuntu jammy and Debian bookworm use pipewire by default. But it isn't started by default due to pulseaudio being installed too (and we add ConditionPathExists=|!/usr/bin/pulseaudio to pipewire.service).
Steps to reproduce
- Build and start Ubuntu jammy template
- See (hear?) audio not working, neither pipewire nor pulseaudio service is running
Expected behavior
Audio works out of the box using pipewire.
Actual behavior
Pipewire service not started.
Enabling pipewire qvm-service manually works as a workaround.
The bug is that PulseAudio got installed at all, which it really shouldn’t be.
Well, maybe it doesn't need to be there, but apparently something pulls it in via dependency (looks like ubuntu-desktop meta-package). And installing pulseaudio (that apparently Ubuntu allows in parallel to Pipewire) should not break audio. We need some better way of choosing which one is started.
It seems pipewire-pulse.socket has Conflicts=pulseaudio.socket and it's enough to not start them in parallel (and I guess also to prefer PW over PA, the latter doesn't have symmetric Conflicts entry). Maybe we can do it this way?
That should work. Should I just get rid of the condition lines in the unit files?
Worth a try. We'll need to test the following combinations:
- Debian 12 with just pulseaudio installed
- Debian 12 with pulseaudio and pipewire installed (no qvm-service set)
- Debian 12 with just pipewire installed
- Same for Fedora 37 or 38 (I hope it doesn't matter which one)
In all the cases, there should be exactly one sound server running, not two, not zero.
Can the PipeWire audio agent just conflict with the PulseAudio package? The current design was intended to make things easier to test, but it seems to be causing enough problems in practice that it is just not worth it.
Can the PipeWire audio agent just conflict with the PulseAudio package?
On a package dependency level - no. That would prevent installing packages that depend (directly or indirectly) on both. For example this applies to ubuntu-desktop, which would be rather fatal (would make template impossible to build).
I think having PulseAudio only start if PipeWire is missing, and ensuring that pipewire-pulse is present if PipeWire is installed, should be enough.
Fixed in https://github.com/QubesOS/updates-status/issues/3744 (ensures that Ubuntu jammy uses pulseaudio, and Debian bookworm has pipewire-pulse installed)
This problem also seems to exist in R4.1. I updated my Debian 11 template to Debian 12, and now audio does not work anymore. More specifically, previously tools like pavucontrol would show an output device like "Qubes Audio Sink" or something like that, now I don't see that anymore. If I attach an USB audio card directly to the VM, then that works as before, so audio does not seem to be broken in general in the template, only the Qubes specific part.
Some pipewire things seem to be running:
zsh % ps -Aef | grep pipe
user 714 689 0 16:13 ? 00:00:01 /usr/bin/pipewire
user 719 689 0 16:13 ? 00:00:01 /usr/bin/pipewire-pulse
and
zsh % pactl info
Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 118
Tile Size: 65472
User Name: user
Host Name: disp4820
Server Name: PulseAudio (on PipeWire 0.3.65)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 7799:8aac
From https://github.com/QubesOS/qubes-meta-packages/commit/747fee2b86c01f39efb47f4137a1461de5b5d69d it seems to me that perhaps I should install the pipewire-qubes package, but that does not seem to exist for R4.1 with bookworm.
Will that package be backported to R4.1 or will pipewire not be supported in 4.1?
@maltesl: (1) removing all pipewire packages and (2) reinstalling both, pulseaudio and pulseaudio-qubes solved this issue on my debian-11 -to- debian-12 in-place upgrade template. Give it a try!
(Qubes R4.2) I removed pipewire-qubes in debian 12 template and replaced it with pulseaudio-pipewire = worked!
Well why i did that because thats as well the case in fedora 38 template, pipewire-qubes not installed and pulseaudio-qubes installed/used instead:
so what does "PipeWire support" mean, like we test that ourselves by playing with pipewire-qubes and report back issues or this is a bug that its not working.. im not sure.
@TNTBOMBOM PipeWire in R4.2 is expected to work and is installed by default in several templates IIRC. PipeWire in R4.1 may or may not work.
Possibly this bug isn't fixed yet even for 4.2, see #8805.
I tried fixing it by removing everything pipewire-related in debian-12 and installing pipewire-pulseaudio in dom0, but that didn't work so far - I can see working audio inside debian-12 via pavucontrol, but all the incoming channels in dom0 are missing.
I also tried removing everything related to pipewire in dom0, but that didn't work either.
What exactly is supposed to be running in dom0 in 4.2? pipewire, pulseaudio, really both or pipewire with pipewire-pulseaudio? @DemiMarie ?
@3hhh PulseAudio in dom0 is the default, but PipeWire + PipeWire-PulseAudio should also work so long as a PipeWire session manager (such as WirePlumber) is also installed. Having both PipeWire-PulseAudio and PulseAudio should not be possible (due to Conflicts: dependencies) and indicates that something went wrong. Having PipeWire and PulseAudio both present is also likely to be broken, as both will fight for control of the sound card.
(Qubes R4.2) I removed pipewire-qubes in debian 12 template and replaced it with pulseaudio-pipewire = worked!
No need this action anymore, pipewire work as expected, more details:
https://github.com/QubesOS/qubes-issues/issues/8896#issuecomment-1960560934