Setting up an audio VM

Well…

Can you play sound as sudo?

Are you willing to paste back the output of

[user@dom0 ~]$ sudo fuser -v /dev/snd/*

also you may try to add the user to audio group

[user@sys-audio ~]$ sudo gpasswd -a user audio

Do you use cacher?

Output of sudo fuser -v /dev/snd/* on dom0 (as implied by the prompt) is NOTHING with the sys-audio running, and is the following if sys-audio is not running:

[user@dom0 user]$ sudo fuser -v /dev/snd/*
                     USER        PID ACCESS COMMAND
/dev/snd/controlC0:  root       3168 f.... alsactl
                     user       5433 F.... pulseaudio
/dev/snd/pcmC0D3p:   user       5433 F...m pulseaudio
/dev/snd/timer:      user       5433 f.... pulseaudio

With sysaudio running, on sys-audio, the same command returned nothing. (I have a sneaking suspicion it should have returned something.) Consistent with sys-audio unable to see my devices even though it has them assigned to it.

Seriously, is it possible I’m just missing some blasted driver on sys-audio?

On sys-audio adding user to the audio group had no effect…well, actually, it seems to have bunged it up worse. I no longer see signs of my music-playing qube in sys-audio pavucontrol, and that’s true for both sudo and non-sudo. (Note: It may be something else; issuing sudo gpasswd -d user audiio (to remove user from the group) doesn’t appear to have helped restore it.)

EDIT: I repeated the process, now it’s back to the way it was. PFM. So as before, it seems to be passing audio to sys-audio, and sys-audio doesn’t know how to play it. pavucontrol sees music coming in, and is sending music out–to “dummy”

ANOTHER EDIT (sorry)…apparently running my music player as sudo means that the signal no longer reaches sys-audio. In pavucontrol, It sees that the music VM is connected to it, just no signal. I’ve gone back and forth running clementine as myself or with sudo; sudo doesn’t send the audio signal from the music VM to sys-audio, even though running it as user does.

And yes, I use cacher.

Sorry I wasn’t clear enough. I meant on

[user@sys-audio ~]$ sudo aplay /usr/share/sounds/alsa/Front_Center.wav

Whatever I suggested I tested on my system, and nothing breakes.
Beside sound card, the only other differences between yours and mine is that I use fedora-36-minimal as a template for sys-audio, and I have pipewire installed.

You may try to set sys-firewall temporarily as updateVM in your policies, then to restart qybesd

[user@dom0 ~]$ sudo systemctl restart qubesd

then to try to install pipewire in your sys-audio template

I don’t know which kernel you use, but I’m pretty sure intel sound driver is there for your card anyway…

Other than all these, I’m pretty out of ideas, sorry.

I’m not sure if you installed pipewire-uitls actually. I never suggested you to install package named `pipewire’?

Second one first.

I reran the command to produce the output that I pasted in for you. As it happens, I mistyped it the second time around.

Trying to do an install of pipewire-utils leads to essentially the same result. It complains about some repository not being available, then checks a large number of mirrors and fails every single time. I may or may not have typed the name correctly the first time around.

OK: Here’s the aplay:

[user@sys-audio ~]$ sudo aplay /usr/share/souds/alsa/Front_Center.wav
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused

aplay: main:831: audio open error: Connection refused

Disabling cacher will be a bit more work. I’ll get back to you on that. (It’s more than just changing the policies, some stuff has to change in the fedora template itself.)

OK, I finally managed to get pipewire-utils installed. (Why the cacher only interferes with that particular package is a mystery to me!)

And unfortunately, it made no dang difference. Same thing; pavucontrol shows music coming into sys-audio, it shows music going out, but it’s going to “Qubes vchan Output (plugged in)” and that apparently connects to nothing.

I reissued the dnf install commands (of which that was a part) and nothing else updated or reinstalled.

So, with you being out of ideas for now, I guess at this point it’s time to throw in the towel. Time to set my music qube to dom0, and reboot.

Thank you very, very much for the effort.

1 Like

Sorry to hear. But, if it works in dom0 under f32, it should work without an issue under f36. Let it just lay over for some time until it occurs what else can be done…
There are some things to try still

It’s not clear if you rebooted Qubes after this and not sys-audio.

Also, what

[user@sys-audio ~]$ aplay -l
[user@sys-audio ~]$ qvm-start-daemon --all --watch

gives as output, etc…

Also, I think it would be a good idea to open separate topic, something like

No HDMI sound output from sys-audio

because, now everything else is set, it looks. It would make it more visible to others to help, although

aplay -l

both in dom0 when sys-audio shut down and running, and in sys-audio when running could tell us a lot at this point.

Yes, I rebooted the physical machine, restarting QubesOS and dom0, after creating that 50-* file. (I’ve noticed people say “restart” when they’re talking about a VM…and that’s what I assumed here.)

Luckily I haven’t rebooted yet to restore dom0 as audio vm. Let’s see…

aplay -l returns:

**** List of PLAYBACK Hardware Devices ****

qvm-start-daemon --all --watch

Another GUI daemon process (with PID 705) is already running

Note that I basically never needed to bother with putting those two desktop files into autostart because the daemon and pulseaudio were starting without them.

(As a side note, since I am working another issue–I don’t think .config/autostart actually autostarts in Debian–but this is Fedora, so it’s only a side note.)

This is good.

This isn’t good but it narrowed down the issue, although I’d expected something like

aplay: device_list:xxx: no soundcards found…

And when you run this command in dom0 in both cases stated above?

with dom0 NOT in control of the soundcard (i.e., sys-audio has run):
same result with the daemon.

aplay: device_list:274: no soundcards found...

(Which is EXACTLY the format you expected.)

I will now reboot to get the card back to dom0 and try the same two commands in dom0.

EDIT: Having rebooted:
Daemon with dom0 as sound: same result (Another GUI daemon process … is already running.

I get a LONG list of devices back from aplay -l.

card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 11: HDMI 5 [HDMI 5]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 12: HDMI 6 [HDMI 6]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 13: HDMI 7 [HDMI 7]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 14: HDMI 8 [HDMI 8]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 15: HDMI 9 [HDMI 9]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 16: HDMI 10 [HDMI 10]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 17: HDMI 11 [HDMI 11]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Ok, next step would be to assure which device is the right output device (in order to know what to expect once recognized in sys-audio)

[user@dom0 ~] $ aplay -D plughw:0,x /usr/share/sounds/alsa/Front_Center.wav

where x is the device number from the list above (0 is the sound card number, but you obviously have one)

In sys-audio, does

$ sudo lspci -k -v

shows any audio device? What is the output?

If not, do different kernels in sys-audio (5.x) help?

And probably the last one. In dom0

sudo echo “options snd-intel-dspcfg dsp_driver=1” > /etc/modprobe.d/50-alsa.conf

Reboot just in case, and try aply -l, or lspci, or whatever above.

Got it right the first time, device 3. (0,3) is the only one I hear sound through. Albeit a bit choppy sounding.

sys-audio: sudo lspci -k -v actually does show an audio device. It also shows a bunch of other stuff:

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
	Subsystem: Red Hat, Inc. Qemu virtual machine
	Flags: bus master, fast devsel, latency 0

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
	Subsystem: Red Hat, Inc. Qemu virtual machine
	Physical Slot: 1
	Flags: bus master, medium devsel, latency 0

00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [ISA Compatibility mode-only controller, supports bus mastering])
	Subsystem: Red Hat, Inc. Qemu virtual machine
	Physical Slot: 1
	Flags: bus master, medium devsel, latency 0
	Memory at 000001f0 (32-bit, non-prefetchable) [virtual] [size=8]
	Memory at 000003f0 (type 3, non-prefetchable) [virtual]
	Memory at 00000170 (32-bit, non-prefetchable) [virtual] [size=8]
	Memory at 00000370 (type 3, non-prefetchable) [virtual]
	I/O ports at c200 [virtual] [size=16]
	Kernel driver in use: ata_piix
	Kernel modules: pata_acpi, ata_generic

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
	Subsystem: Red Hat, Inc. Qemu virtual machine
	Physical Slot: 1
	Flags: bus master, medium devsel, latency 0, IRQ 9
	Kernel modules: i2c_piix4

00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
	Subsystem: XenSource, Inc. Xen Platform Device
	Physical Slot: 2
	Flags: bus master, fast devsel, latency 0, IRQ 24
	I/O ports at c000 [size=256]
	Memory at f0000000 (32-bit, prefetchable) [size=16M]
	Kernel driver in use: xen-platform-pci

00:04.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Red Hat, Inc. Device 1100
	Physical Slot: 4
	Flags: bus master, fast devsel, latency 0
	Memory at f1000000 (32-bit, prefetchable) [size=16M]
	Memory at f2116000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at 000c0000 [disabled] [size=128K]
	Kernel modules: bochs

00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10) (prog-if 20 [EHCI])
	Subsystem: Red Hat, Inc. QEMU Virtual Machine
	Physical Slot: 5
	Flags: bus master, fast devsel, latency 0, IRQ 39
	Memory at f2117000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:06.0 Audio device: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
	Subsystem: Intel Corporation Device 3002
	Physical Slot: 6
	Flags: bus master, fast devsel, latency 64, IRQ 69
	Memory at f2100000 (64-bit, non-prefetchable) [size=16K]
	Memory at f2000000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [50] Power Management version 3
	Capabilities: [80] Vendor Specific Information: Len=14 <?>
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl

Now this is interesting. the sudo echo produces a different 50-alsa.conf file!

options snd-intel-dspcfg dsp_driver=1

OK, now I am going to do the reboot. Be back shortly.

***REBOOTED, running sys-audio

the music qube still doesn’t play over the loudspeakers (same thing, sys-audio gets the sound and sends it off to nowhere.)

aplay -l now returns `aplay: device_list:274: no soundcards found…’ rather than what looks like the header to a table. So maybe the “new” 50- file did something…

I’m not at all sure what to put in for the aplay -D plughw: command. Using 0,3 (which worked on dom0) did not work and returned:

ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for 0
aplay: main:831: audio open error: No such file or directory

Running that command on dom0 with sys-audio running:

ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card
aplay: main:830: audio open error: No such file or directory

(Which I suspect is no surprise.)

This is good. What the command produces in dom0 regarding audio device (you don’t have to shut down sys-audio, or reboot most probably)?

lspci -k -v on dom0 (other devices omitted; if you need one of them let me know). I did not shut down sys-audio and reboot.

00:1f.3 Audio device: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
        DeviceName: Onboard - Sound
        Subsystem: Intel Corporation Device 3002
        Flags: bus master, fast devsel, latency 32, IRQ 16
        Memory at 603d1a0000 (64-bit, non-prefetchable) [size=16K]
        Memory at 603d000000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: [50] Power Management version 3
        Capabilities: [80] Vendor Specific Information: Len=14 <?>
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: pciback
        Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl

I notice the kernel driver is different…dom0 is using “pciback” while sys-audio is using “snd_hda-intel”. Also sys-audio doesn’t print the DeviceName but does print a Physical Slot, a different latency under Flags, and things like IRQ and Memory addresses are different (the IRQ and Memory are no surprise to me).

I think it might be interesting to see what happens if sys-audio were to use pciback, but I have no idea how to go about getting it to do so.

(First things first, is it even present on sys-audio? DuckDuckGo indicates “lsmod” can be used to check for drivers; doing lsmod | grep pci on sys-audio gives me:

snd_sof_pci_intel_tgl    16384  0
snd_sof_intel_hda_common   151552  1 snd_sof_pci_intel_tgl
snd_sof_pci            24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof               258048  2 snd_sof_pci,snd_sof_intel_hda_common
snd_soc_acpi_intel_match    69632  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
xhci_pci               20480  0
xhci_pci_renesas       24576  1 xhci_pci
xhci_hcd              348160  1 xhci_pci
xen_pciback            90112  4

and sys-audio shows nearly the same thing, with the prominent exception of xen_pciback being absent:

snd_sof_pci_intel_tgl    16384  0
snd_sof_intel_hda_common   151552  1 snd_sof_pci_intel_tgl
snd_sof_pci            24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof               258048  2 snd_sof_pci,snd_sof_intel_hda_common
snd_soc_acpi_intel_match    69632  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
ehci_pci               20480  0
ehci_hcd              110592  1 ehci_pci

but also xhci is replaced by ehci.

I’m thinking this may not be an issue; xen stuff probably should only be visible to dom0. But perhaps there is a non-xen version of pci_back I should be using in sys-audo? I don’t even know if that question makes sense.

No, no. Everything is OK. But from this point I can’t reproduce any further suggestions. Which would be:
Because of

I’d try this

I can’t quite figure out what that’s talking about, unfortunately.

It sounds like firmware? But if my issue were firmware, I’d not be able to get sound out of my system, ever. Yet dom0 works well as an audio controller.

In broader news, sys-usb is the only working system I haven’t turned into a deb11-minimal template I can rebuild from “scratch” with salt files. (This is another one I can’t do, but it doesn’t work, either.) At some point I might try porting all of these suggested fixes back to my original deb11-minimal attempt (which, when I set it aside because this looked like it might work based on the prior conversation in this thread, was also having the same issue; everything seemed connected together but no sound at the end). Who knows, it might work (but I am not optimistic).

Mucking with sys-usb scares me a bit, but at least I know it can work on this box.

I think I’ll turn my attention to browsers now…most of my “regular” appvms (i.e., not disposable templates) that I should be able to transition away from are browsers devoted to specific topics (e.g., there’s one I use for qubes and qubes-related browsing). Getting those over to some form of split browser would be a huge step forward.

Ok. What I could try was to setup usb-audio based on fedora-36-minimal, and got the same error as you at some point:

aplay: main:831: audio open error: Connection refused

Since I had working usb-fedora-35 qube, I diffed two qubes and I installed in usb-fedora-36-minimal-template (which would be your sys-audio template)

$ sudo dnf install alsa-utils alsa-plugins-pulseaudio pulseaudio-module-bluetooth pulseaudio-qubes pulseaudio-utils
$ sudo dnf install qubes-audio-daemon --allowerasing

After that, I got the sound in minimal AppVm qube, which would be your sys-audio. Try that at least…

Will do.

It’s encouraging that you were able to a) reproduce my issue and b) then solve it!

I started this Fedora effort by using the salt script, which insisted on Fedora 36.

If this works, it might also get debian-11 minimal to work…which was my ultimate goal (I switched because people seemed able to get Fedora working…I figured it might be easier to port a working solution to deb11 than to try to get deb11 working independently). Sometimes supporting multiple distros can be a bad thing…

Yep. Eventually I found fedora much more workable then Debian, so my only Debian qube is cacher actually and we have issues from time to time with it. Everything else is fedora36-minimal.

I still suspect on snd_sof_pci_intel_tgl and I’d try to blacklist it, reboot and tried sys-audio.

Me too. Once created via salt, I just switched template to fedora-36-minimal and installed those packages and voila…