R4.1 Audio does not go from appvm to dom0 in default installation

I installed the new Qubes OS R4.1 on my new laptop (Thinkpad L15 Gen2) and tons of problems arises.

One problem is about audio. I cannot hear sound from AppVMs.

I did not try the sys-audio and any experimental features.

I executes pavucontrol to see the volume in both VMs, and see that, when I am playing music, in the pavucontrol playback inside the playing VM I can see volume rising, indicating the music is playing; however in the dom0 pavucontrol playback I cannot see any sound.

Device should be good since I tested it on Windows before installing Qubes OS R4.1

I currently have no idea how to investigate this problem further. Please give me some advice.

Hello and welcome to Qubes community!

How did you investigate the issue in dom0?

After my investigation, I found this info may be helpful.

In my old laptop (R4.0) the dom0 pacat-simple-vchan outputs like:

Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=3072, prebuf=2052, minreq=1024
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device alsa_output.pci-0000_00_1b.0.analog-stereo (0, not suspended).
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=4096, prebuf=4294967295, minreq=4294967295
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device alsa_input.pci-0000_00_1b.0.analog-stereo (1, not suspended).
Stream device alsa_input.pci-0000_00_1b.0.analog-stereo suspended.

However in R4.1 new machine something is different.

Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=3072, prebuf=2052, minreq=1024
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device **auto_null** (0, not suspended).
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=4096, prebuf=4294967295, minreq=4294967295
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device **auto_null.monitor** (**0**, not suspended).
Stream started.

It seems that pacat-simple-vchan misunderstood the channels, or the protocol changed.

I am still unfamiliar with the pacat-simple-vchan tricks, and am asking for advice.

Did you check output devices in audio mixer in dom0? What happens there while there’s audio playing in AppVM? Is this happening in AppVMs based on different templates (Fedora, Debian)?

Output device is dummy output; no input devices available.

I may need to check my BIOS config …

Update: I/O Port Access, I have disabled:
Wireless Wan, Bluetooth, Memory Card Slot, Integrated Camera, Fingerprint Reader
I enabled Integrated Audio and Microphone.

Update2: lspci has an audio controller
00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)

I searched my hardware name and found that this hardware seems to have problem with drivers in dom0. So I had to try the sys-audio approach. Once I have passed the Audio PCI device to the sys-audio, I can hear the correct sound when I test in sys-audio aplay /usr/share/sounds/alsa/Front_Center.wav.

I cannot find any official tutorial about sys-audio other than Setting up an audio VM - #24 by hamenarin . Thus I tried things in the post, and it seems that VCHAN connection has deadlock or something similar and it is not anything easy to solve for a xen vchan noob like me.

Basically I run the salt script to create the sys-audio VM, installed qubes-audio-daemon qubes-core-admin-client to the fedora-34-xfce and make pulseaudio to boot automatically (qvm-start-daemon --all --watch is already autostart), fixed the policy errors, setting audiovm attribute of related VM correctly (I have set the audiovm of other unrelated appvms to be '', only the VM that I want to hear from to be sys-audio).

I tried to play an MP3 file in my appvm and have no luck. Moreover the MP3 player seems to block when playing.

So I tried manually to execute pulseaudio and pacat-simple-vchan -l <vmid> <vmname> in sys-audio.

I have no luck when I keep restarting pacat-simple-vchan; each time when I restarting pulseaudio, it seems that one CHUNK (0.1s or similar) of sound data of AppVM is consumed and the audio output plays the chunk again and again.

Is there any expert on sys-audio that can help me out?

Are there any traces of this in sudo dmesg? If there is, than install this firmware, and reboot.

Installing alsa-sof-firmware does not help - without alsa-sof-firmware, aplay works, and anything relying on pulseaudio does not work correctly; installing alsa-sof-firmware does not change anything.

I now believe that it is a problem related to pulseaudio on my hardware (Intel Tiger Lake), since not only pacat-simple-vchan does not work, the common media player (parole, for example) also does not work when pulseaudio is on.

dmesg does provide a information that may be related snd_hda_intel 0000:00:06.0: azx_get_response timeout, switch to polling mode: last cmd=0x00170500, so it seems that aplay on alsa correctly uses the polling mode but pulseaudio does not.

Any other suggestion is welcomed.

Update: switch kernel version from 5.10.96 to 5.15.14 does not help anything. azx_get_response still timeout and pulseaudio still does not work.

You can try to add

options snd-hda-intel enable=0,1,0

in /etc/modprobe.d/alsa.conf

This effectively disable my only-existing driver and

snd_hda_intel: probe of 0000:00:06.0 failed with error -2

and aplay -l tells no soundcards found... now

It seems solved now, at least for the output side of sound.

I just edited /etc/pulse/default.pa to make pulseaudio load alsa statically rather than “Automatically load driver modules depending on hardware available”. I will summarize the details later when I solve all audio problem on my laptop.

However the input side does not seem to work out of box.

arecord -l shows the correct device (card 0: PCH [HDA Intel PCH], device 0: ALC257 Analog [ALC257 Analog]) but arecord does not write data to output file other than a header.

Notice that output side works even without alsa-sof-firmware installed; input side does not work even with alsa-sof-firmware.

Any suggestion on how to make my microphone work is welcomed.

It would be helpful to summarize what steps exactly solved output so it could help other users, too.

I will organize the configuration detail and elaborate when all problem is solved. Actually for output it is only a temporary solution since sys-audio itself is an experimental feature with no official instructions. (Actually I am surprised to see that I have to rely on an experimental feature to solve a hardware problem)

Currently I am still in big trouble since my microphone does not work in Qubes OS sys-audio. The mic works in Windows as expected. Booting first in Windows and then reboot to Qubes does not make the mic work, either.

Now I have both output and input working (when I keep my headphone plugged - this situation is a bit different).

I encounter the last problem, after which everything works at least on one configuration. I cannot attach mic to my user appvm.

Failed to attach audio input from sys-audio to appvmname: pulseaudio agent not running

And I am in pain to see /usr/lib/python3.8/site-packages/qubesguidaemon/mic.py summarize ALL subprocess.CalledProcessError as a pulseaudio agent not running.

I have hacked this mic.py and hope I have good luck here.

Fully solved, at least for a given scenario, I can use online meeting software in my appvms. It took me 3 full days.

Summary is here. This does not cover too many details, and you are welcome to make it more complete.

This mainly apply to using Intel Tiger Lake Audio Controller on Qubes R4.1.

  1. Bootstrap sys-audio according to Setting up an audio VM - #24 by hamenarin .
    Most detail is similar, while the template VM of sys-audio may need more work.
    The template VM of sys-audio start from fedora-34-xfce, and install qubes-audio-daemon, qubes-core-admin-client; for better debugging I suggest installing strace gdb busybox pulseaudio-utils but they does not seem necessary.
    Note that the post did not mention that one should manually configure PCI Passthrough for theaudio device. Also, step 7 in the mentioned post does not seem necessary in R4.1 now since qvm-start-daemon startup on boot automatically now.
    Also, /etc/qubes/policy.d/50-sys-audio.policy need more rules than what the post mentions. Add them in later steps until you do not see complaint from sys-audio.

  2. Edit /etc/xdg/autostart/qubes-pulseaudio. start-pulseaudio-with-vchan is an app that is only useful for client VMs, not for a sys-audio. Let’s hack and edit start-pulseaudio-with-vchan into pulseaudio.
    Yes, naked pulseaudio with no arguments.
    Note that pulseaudio and pacat-simple-vchan all write their log by default in ~/.xsession-errors, in case you need it.

  3. /etc/pulse/default.pa is the config file that a naked pulseaudio command uses.
    Look at this part

### Load audio drivers statically
### (it's probably better to not load these drivers manually, but instead
### use module-udev-detect -- see below -- for doing this automatically)
#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-null-sink
#load-module module-pipe-sink

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect

Uncomment the upper part and comment the lower part (load audio drivers statically, not automatically)
Also load-module module-alsa-source device=hw:1,0 the device=... part should be deleted. The final result of the above part should be:

load-module module-alsa-sink
load-module module-alsa-source
load-module module-null-sink
load-module module-pipe-sink
  1. wait for the patch of https://github.com/QubesOS/qubes-issues/issues/7288
  • or, recompile a version of pacat-simple-vchan by yourself
  • or, like me, kill the original pacat-simple-vchan and hack the bind() argument with gdb by b bind; r; p *(short*)$rsi=1; c when manually running pacat-simple-vchan with correct arguments
  1. Above initialized the template for sys-audio. The kernel version of sys-audio does not seem to matter, as both default and latest versions seem good.

  2. Set audiovm of other VMs. In dom0:

qubes-prefs default_audiovm ''
qvm-prefs appvmneedingaudio audiovm sys-audio
  1. Make sure that the headset is plugged and start sys-audio

  2. Run pavucontrol in sys-audio and speak to see whether input device works; you should hear from parole /usr/share/sounds/alsa/Front_Center.wav. If input device and output device do not work inside sys-audio, you need to try better; otherwise congratulations and you can continue to the last step

  3. Run your appvm needing audio. In dom0 pass mic to your appvm, and if pulseaudio agent not running error message appears, check out step 4 in this post. When mic has been passed, your appvm should be able to play sounds and record from mic. Congratulations.

Note that I can only make it work when I plug my headphone, and I did not test whether restarting some of VMs or suspension makes the sound work. However I believe this is a good start.