Audio issues since last update

Since the last dom0 update, when all the audio packages were renewed, the error that the audio output is noisy all the time has disappeared. But now there are other errors.

A) After the computer was in sleep mode, the audio output is so bad that you can no longer understand the voices.

B) If you do something in other VMs that takes up a little CPU or RAM, the audio output changes. The pitch of the music played briefly drops or rises a little. This sounds strange.

I was able to solve the problem that the audio output is no longer usable after suspend with a dom0 script:

systemctl --user restart pipewire

However, the VMs of a certain template are then no longer displayed in the Pulseaudio playlist. So there is no more sound from these VMs until the VMs are restarted.

Would anyone know which command can be used to make the VMs output sound again without restarting them?

Did you try to restart pipewire in VMs?
Or if you have pulseaudio in VMs then try to kill the pulseaudio process and run “start-pulseaudio-with-vchan”.

Restarting pipewire in VMs did not help. Then I installed pulseaudio in the template. “Systemctl --user start pulseaudio” in the VM did not solve the problem. Command “start-pulseaudio-with-vchan” which you mentioned is unknown. How can I run this command?

What template is causing this issue?

I think it should be in qubes-related pulseaudio package, maybe in pulseaudio-qubes.
Don’t install both pulseaudio and pipewire in template at the same time:

I installed pulseaudio and pulseaudio-qubes and removed pipewire and pipewire-qubes. Now I can run the command “start-pulseaudio-with-vchan” in the VM. But it does not help. I have still to restart the VM because there is only dummy output in the VM. After restart I have vchan sink again there in the VM. So which command could be the solution?

?

It is a standard debian 12 gnome template. It has the most packages of all templates installed including some kde stuff. I have no problems with VMs that are based on an adapted debian 12 minimal template.

I don’t have default debian 12 gnome template to test, but original debian-12-xfce template without any modifications works without any problems.
Try to reproduce this issue using default debian-12 gnome template with latest updates and without any modifications.
If it’ll work properly then some of your modifications to the template is causing this issue.

I seem to be having similar issues with my appvms that are based on the debian (xfce in my case) template, it does not seem to be an issue with fedora though (AFAIK). I tried the line that @Singer mentioned:

systemctl --user restart pipewire

But that didnt seem to do anything?
In addition, when I start up a debian based vm I hear nothing, I can literally unplug then replug back in the audio jack and then I get sound?
I thought I remember having an issue similar to this awhile ago (last year?) and the “fix” was something using pavucontrol but I have searched and have not found anything that seems to resolve this?
I am not sure where to start with this.

Left mouse click on the volume icon in dom0 tray → Audio mixer → Output devices → check the “Set as fallback” option for your sound device. By setting device as fallback you can set the default device that would be used by qubes.

Wow, your posting/helping karma must be off the charts :slight_smile:

Well, small detail I neglected to consider :face_with_diagonal_mouth: I’m using KDE.

I did go back into XFCE and apparently I didnt even need to do anything as it just worked. So I guess that helps narrow it down quite a bit? Is there a “set as fallback” option via the KDE audio settings that you know of? Perhaps it would be more appropriate to post in the KDE thread?

I think it should be the same for KDE, but I didn’t use it so I’m not sure.
You can run pavucontrol command in dom0 terminal to run the PulseAudio Volume Control if you don’t have it in KDE system tray.

Ok. So. No idea why, but I logged out, logged back in with KDE (x11, not wayland) and audio for at least one of the debian based templates works?! BUT, not totally. It sounds normal (no crackling) but its still silent until I unplug the audio jack and then plug it back in. I’m just plugging my little 2.1 computer speakers directly into the audio jack on the mobo, no usb cards etc. When I look its “analog stereo output + stereo input” but when I unplug it the playback device goes to “digital stereo (HDMI) output + stereo input” but then when I plug it goes back to “analog stereo output + stereo input”. I guess this is the “manual version” of changing ti playback device via the audio interface - that I try to play another bit of audio and in order to hear the sound I have to switch from “analog stereo output + stereo input” to something else then back to “analog stereo output + stereo input” and I can hear it again?
This is bizarre?

while I’m at it, I’m wholly unclear if I am running pipewire (for some reason I thought qubes switched to pipewire?) or pulseaudio? I tried a few things to get some clarity but am just more confused:

[bob@dom0 ~]$ ps -ef | grep pulseaudio
bob         7805    7598  0 13:39 ?        00:01:56 /usr/bin/pulseaudio --daemonize=no --log-target=journal
bob        10681   10085  0 14:10 ?        00:00:30 /usr/bin/systemsettings kcm_pulseaudio
bob        14191   10632  0 17:19 pts/12   00:00:00 grep --color=auto pulseaudio
[bob@dom0 ~]$ ps -ef | grep pipewire
bob         7608    7598  0 13:39 ?        00:00:00 /usr/bin/pipewire
bob        14196   10632  0 17:19 pts/12   00:00:00 grep --color=auto pipewire
[bob@dom0 ~]$ systemctl --use status pipewire.service
â—Ź pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
     Active: active (running) since Tue 2024-05-28 13:39:50 EDT; 3h 39min ago
TriggeredBy: â—Ź pipewire.socket
   Main PID: 7608 (pipewire)
      Tasks: 3 (limit: 4624)
     Memory: 4.9M
        CPU: 737ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─7608 /usr/bin/pipewire

May 28 14:21:03 dom0 pipewire[7608]: spa.alsa: 'hdmi:0': playback open failed: Device or resource busy
May 28 14:21:03 dom0 pipewire[7608]: mod.adapter: 0x5abe0385aae0: can't get format: Device or resource busy
May 28 14:24:34 dom0 pipewire[7608]: spa.alsa: 'hdmi:0': playback open failed: Device or resource busy
May 28 14:24:34 dom0 pipewire[7608]: mod.adapter: 0x5abe0385aae0: can't get format: Device or resource busy
May 28 14:28:17 dom0 pipewire[7608]: spa.alsa: 'hdmi:0': playback open failed: Device or resource busy
May 28 14:28:17 dom0 pipewire[7608]: mod.adapter: 0x5abe0385aae0: can't get format: Device or resource busy
May 28 14:29:31 dom0 pipewire[7608]: spa.alsa: 'front:0': playback open failed: Device or resource busy
May 28 14:29:31 dom0 pipewire[7608]: mod.adapter: 0x5abe0385aae0: can't get format: Device or resource busy
May 28 14:31:44 dom0 pipewire[7608]: spa.alsa: 'hdmi:0': playback open failed: Device or resource busy
May 28 14:31:44 dom0 pipewire[7608]: mod.adapter: 0x5abe0385aae0: can't get format: Device or resource busy
[bob@dom0 ~]$ systemctl --use status pulseaudio.service
â—Ź pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled)
     Active: active (running) since Tue 2024-05-28 13:39:52 EDT; 3h 39min ago
TriggeredBy: â—Ź pulseaudio.socket
   Main PID: 7805 (pulseaudio)
      Tasks: 7 (limit: 4624)
     Memory: 10.3M
        CPU: 1min 56.536s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pulseaudio.service
             ├─7805 /usr/bin/pulseaudio --daemonize=no --log-target=journal
             └─7920 /usr/libexec/pulse/gsettings-helper

May 28 16:09:43 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:09:44 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:15:44 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:15:46 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:15:46 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:25:11 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 16:25:13 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 17:02:26 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 17:02:28 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.
May 28 17:02:28 dom0 pulseaudio[7805]: Disabling timer-based scheduling because running inside a VM.

Are you able to open PulseAudio Volume Control using pavucontrol command?
Did you change “Set as fallback” device in “Output Devices”?
You can also change the playback device in “Playback” tab.

I guess something is wrong in your dom0, it should be either pipewire or pulseaudio, not both.
Switch your audio to pipewire in dom0, it should remove pulseaudio:

Thanks for the link for migrating. Before I go that route do you have an idea how I might have ended up with pulseaudio if pipewire is supposed to be installed? I am 99% sure I did not inadvertently install pulseaudio - anyway, I just don’t want to do it (whatever it was) again that leaves me with both installed.

As for setting as fallback, i am pretty sure I did it when I had tried logging out (of KDE) and logged in with XFCE. When opened pavcontrol (from within KDE) it seems that the “built in audio analog stereo” was indeed set as a fallback, though I am still having issues if i try to play something else either in another app (in the same qube or in another qubes) it messes up the playback device (i have to select another device then re-select “analog stereo output + stereo input”. I’ll try the migration post and see if that helps though I am open to reinstalling if i can nail down what point it was that I somehow installed pulseaudio (this would most likely have to have been done via dom0 right? or would it be in the debain template)(I looked at my history in both and it doesnt look like any of the commands i issued would have installed PA?)

I don’t know, @marmarek suggested that it could be because of KDE:

Can you check what pulled in pipewire in dom0? I don’t see it neither system updated from 4.1 nor in a fresh install. Maybe KDE?

Yes.

It shouldn’t be related to the templates.

1 Like

KDE seems like the most logical culprit as when I am in XFCE it all “just works”. I do so like KDE and am trying to figure if I’d be getting myself into more trouble getting XFCE setup for a workflow that works for me or try to get KDE working :frowning:

But yeah, I agree with marmarek - I will check in the KDE thread to get some thoughts there.

Yeeeeees! marmarek’s line:
qubes-dom0-update --switch-audio-server-to=pipewire
worked!
Or so far, I only tested a few things but so far so good. Also, in the KDE thread it seems that KDE does add pulseaudio back in and there are a few others having issues.
Solved! Thanks AGAIN.

Had sound issues in Whonix after this update. No sound at all. Fixed by installing pipewire-pulse in whonix-workstation template.