I recently upgraded from qubes 4.1 to 4.2, and so far everything’s been great except for the fact that my audio no longer works. Not only do I not get any audio for any qubes, but also none of my internal speakers, external speakers, external microphone…etc, register or show up in the qubes “audio mixer”/“Dom0 volume control” tool. The only input device it shows is “monitor of dummy output,” and the only output device is “dummy output.” Any advice on how to fix this would be much appreciated, thanks.
Check the journalctl in dom0 for pulseaudio / snd / alsa / sound / etc strings and errors related to them.
How do I access that?
Run this command in dom0 terminal:
journalctl -b
Press h key there to see the commands list.
Okay, I looked through the logs, but (and please forgive my ignorance) what exactly am I looking for?
You need to look for related errors or failures.
What’s the output of this command?
journalctl -b | grep -i -e snd -e sound -e alsa -e sof -e audio
The output for
is:
Dec 24 12:26:45 dom0 kernel: software IO TLB: area num 4.
Dec 24 12:26:45 dom0 kernel: Performance Events: unsupported p6 CPU model 62 no PMU driver, software events only.
Dec 24 12:26:45 dom0 kernel: pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
Dec 24 12:26:45 dom0 kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Dec 24 12:26:45 dom0 kernel: software IO TLB: mapped [mem 0x000000016ee00000-0x0000000172e00000] (64MB)
Dec 24 12:27:08 dom0 kernel: snd_hda_intel 0000:02:00.1: Disabling MSI
Dec 24 12:27:08 dom0 kernel: snd_hda_intel 0000:02:00.1: Handle vga_switcheroo audio client
Dec 24 12:27:08 dom0 kernel: snd_hda_intel 0000:02:00.1: bound 0000:02:00.0 (ops nv50_audio_component_bind_ops [nouveau])
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3220: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) type:line
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: inputs:
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x1a
Dec 24 12:27:08 dom0 kernel: snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18
Dec 24 12:27:08 dom0 kernel: input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:02:00.1/sound/card1/input4
Dec 24 12:27:08 dom0 kernel: input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.0/0000:02:00.1/sound/card1/input5
Dec 24 12:27:08 dom0 kernel: input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
Dec 24 12:27:08 dom0 kernel: input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
Dec 24 12:27:08 dom0 kernel: input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
Dec 24 12:27:08 dom0 kernel: input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
Dec 24 12:27:15 dom0 systemd[1]: alsa-restore.service - Save/Restore Sound Card State was skipped because of a failed condition check (ConditionPathExists=!/etc/alsa/state-daemon.conf).
Dec 24 12:27:15 dom0 systemd[1]: Started alsa-state.service - Manage Sound Card State (restore and store).
Dec 24 12:27:15 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=alsa-state comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
Dec 24 12:27:15 dom0 systemd[1]: Reached target sound.target - Sound Card.
Dec 24 12:27:15 dom0 kernel: audit: type=1130 audit(1703438835.048:148): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=alsa-state comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
Dec 24 12:27:15 dom0 alsactl[2381]: alsactl 1.2.9 daemon started
Dec 24 12:27:43 dom0 systemd[3820]: Listening on pulseaudio.socket - Sound System.
Dec 24 12:28:05 dom0 systemd[4302]: Listening on pulseaudio.socket - Sound System.
Dec 24 12:28:12 dom0 systemd[4302]: Starting pulseaudio.service - Sound Service…
Dec 24 12:28:13 dom0 rtkit-daemon[4716]: Successfully made thread 4711 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ high priority at nice level -11.
Dec 24 12:28:13 dom0 pulseaudio[4711]: Disabling timer-based scheduling because running inside a VM.
Dec 24 12:28:13 dom0 rtkit-daemon[4716]: Successfully made thread 4728 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 12:28:13 dom0 pulseaudio[4711]: Disabling timer-based scheduling because running inside a VM.
Dec 24 12:28:13 dom0 rtkit-daemon[4716]: Successfully made thread 4729 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 12:28:13 dom0 pulseaudio[4711]: stat(‘/etc/pulse/default.pa.d’): No such file or directory
Dec 24 12:28:13 dom0 systemd[4302]: Started pulseaudio.service - Sound Service.
Dec 24 12:28:13 dom0 pulseaudio[4711]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Dec 24 12:28:13 dom0 pulseaudio[4711]: Most likely this is a bug in the ALSA driver ‘snd_hda_intel’. Please report this issue to the ALSA developers.
Dec 24 12:28:13 dom0 pulseaudio[4711]: We were woken up with POLLOUT set – however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Dec 24 12:28:15 dom0 systemd[3820]: Closed pulseaudio.socket - Sound System.
Dec 24 12:29:07 dom0 rtkit-daemon[4716]: Successfully made thread 5595 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 12:57:37 dom0 pulseaudio[4711]: Disabling timer-based scheduling because running inside a VM.
Dec 24 12:57:37 dom0 rtkit-daemon[4716]: Successfully made thread 7871 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 12:57:37 dom0 kernel: snd_hda_intel 0000:02:00.1: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
Dec 24 12:58:11 dom0 rtkit-daemon[4716]: Successfully made thread 7874 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 13:01:58 dom0 pulseaudio[4711]: Disabling timer-based scheduling because running inside a VM.
Dec 24 13:01:58 dom0 rtkit-daemon[4716]: Successfully made thread 9705 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 13:02:05 dom0 rtkit-daemon[4716]: Successfully made thread 9751 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Dec 24 13:48:52 dom0 pulseaudio[4711]: Disabling timer-based scheduling because running inside a VM.
Dec 24 13:48:52 dom0 rtkit-daemon[4716]: Successfully made thread 14209 of process 4711 (/usr/bin/pulseaudio) owned by ‘1000’ RT at priority 5.
Log looks good, not sure why it’s not working.
What do you have in Configuration tab in Dom0 volume control?
When I first had the problem the configuration tab only had the HDMI option which was set to off, the built in audio did not show up. However just a few minutes ago my PC crashed and when it booted up again I had audio. Everything works now, I have no idea why, seeing how I restarted it many times before. Thank you so much for your time and help.
I have the exact same issue
I am able to resolve it each boot by doing this:
rm -rf ~/.config/pulse
pulseaudio -k
but it is definitely really annoying. I hope theres a more longterm fix
1 Like
This sequence of actions posted on a duplicate post for this same issue solved it for me:
Not sure if it’s a proper solution, but for the moment it did the job
I have the same problem.
To solve, after each boot, I have to go to “Volume control” →"Configuration" → “Profile” and then switch from “Play HiFi Quality Music” to “off” and then again to “Play HiFi Quality Music”.
I hope there is a definitive way to fix it.
Thanks
One possibly helpful set of tips:
You may have to get a bit creative since I learned by experiment that pipewire was truly up even though (alternative proof: ps aux | grep pipewire):
systemctl pipewire
or
systemctl pipewire.socket
did not show it as up but
systemctl --user pipewire
does/did.
Once you know enough to tug pipewire down (we’re going to disable pipewire for now since pulseaudo isn’t going away yet - the issue is that they are fighting over the same territory!):
systemctl --user disable pipewire
systemctl --user mask pipewire
systemctl --user stop pipewire
Sometimes, if you stop it first then disable it for instance, you still need another stop after disable/mask to ensure pipewire remains offline (restarts itself too quickly).
To verify that you have sound devices that are associated with anything other than either PulseAudio or Pipewire (my case there were often a mix of the two on the same PC):
fuser -v /dev/snd/*
Maybe even need to kill PulseAudio so that it can restart & grab anything it couldn’t grab earlier:
pulseaudio --kill
And if you see only one program capturing sound devices great but otherwise, dig some to find & disable the other program (I noticed wireplumber on one but that disappeared along with pipewire when I killed pipewire so is related).
See then if you can properly test your audio again. So long as only one set is actively attaching to resources they could both be installed so far as I can see.
1 Like
Do you have both pulseaudio and pipewire running in both dom0 and your VM or just in one of them?
For me it was just dom0.
I uninstalled pipewire via dnf (kept pulseaudio as it’s apparently supposed to run in dom0), but couldn’t yet get pulseaudio working.
Can anyone with working 4.2 audio post the output of systemctl --user status pulseaudio from dom0 as non-root user?
I’d like to compare it with my broken setup.
Here’s mine:
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled)
Active: active (running) since Sun 2023-12-31 14:18:30 CET; 36min ago
TriggeredBy: ● pulseaudio.socket
Main PID: 5949 (pulseaudio)
Tasks: 8 (limit: 4619)
Memory: 21.0M
CPU: 16.511s
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pulseaudio.service
├─5949 /usr/bin/pulseaudio --daemonize=no --log-target=journal
└─6156 /usr/libexec/pulse/gsettings-helper
Dec 31 14:18:29 dom0 systemd[5718]: Starting pulseaudio.service - Sound Service...
Dec 31 14:18:29 dom0 pulseaudio[5949]: Disabling timer-based scheduling because running inside a VM.
Dec 31 14:18:30 dom0 pulseaudio[5949]: Disabling timer-based scheduling because running inside a VM.
Dec 31 14:18:30 dom0 pulseaudio[5949]: Disabling timer-based scheduling because running inside a VM.
Dec 31 14:18:30 dom0 pulseaudio[5949]: stat('/etc/pulse/default.pa.d'): No such file or directory
Dec 31 14:18:30 dom0 systemd[5718]: Started pulseaudio.service - Sound Service.
Dec 31 14:18:55 dom0 pulseaudio[5949]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Dec 31 14:18:55 dom0 pulseaudio[5949]: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Dec 31 14:18:55 dom0 pulseaudio[5949]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
I kind of have the same issues: no audio in VMs started based on the Fedora-38 template. But, I have sound in VMs based on whonix-workstation-17. I’m getting sound out the volume control widget. I’m not looking forward to another dive into the sound system, as I thought I had this issue put to bed years ago.
Thanks @DVM !
Unfortunately mine looks pretty much the same. The only difference being that I don’t have /usr/libexec/pulse/gsettings-helper. I just got it back by installing pulseaudio-module-gsettings in dom0, but that didn’t change anything so far.
here is mine from after my audio started working:
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled)
Active: active (running) since Thu 2023-12-28 10:18:21 EST; 3 days ago
TriggeredBy: ● pulseaudio.socket
Main PID: 5111 (pulseaudio)
Tasks: 7 (limit: 4618)
Memory: 10.6M
CPU: 6min 16.465s
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pulseaudio.service
├─5111 /usr/bin/pulseaudio --daemonize=no --log-target=journal
└─5166 /usr/libexec/pulse/gsettings-helper
Dec 28 10:18:20 dom0 systemd[4761]: Starting pulseaudio.service - Sound Service…
Dec 28 10:18:21 dom0 pulseaudio[5111]: Disabling timer-based scheduling because running inside a VM.
Dec 28 10:18:21 dom0 pulseaudio[5111]: Disabling timer-based scheduling because running inside a VM.
Dec 28 10:18:21 dom0 pulseaudio[5111]: stat(‘/etc/pulse/default.pa.d’): No such file or directory
Dec 28 10:18:21 dom0 systemd[4761]: Started pulseaudio.service - Sound Service.
Dec 28 16:27:52 dom0 pulseaudio[5111]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Dec 28 16:27:52 dom0 pulseaudio[5111]: Most likely this is a bug in the ALSA driver ‘snd_hda_intel’. Please report this issue to the ALSA developers.
Dec 28 16:27:52 dom0 pulseaudio[5111]: We were woken up with POLLOUT set – however a subsequent snd_pcm_avail() returned 0 or another value < min_ava
Audio will sometimes quit working for me in vms but on the Debian-12 template. Only started once I went to kernel-latest in dom0. Most times restarting the VM resolves the issue. Haven’t seen the issue really since 4.2 went final though so maybe it was fixed upstream knock on wood.
(edit: might also be because I did the comment out module-suspend-on-idle workaround now I think about it)