Setting up an audio VM

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…

OK, I did the install…except that it said there was nothing to do! In other words they’re already installed. I fired up sys-audio and did a dnf-list to confirm that.

OK, that’s just weird.

The next thing I try is repeating the whole thing in fedora-36-minimal

OK. Downloaded fedora-36-minimal. Cloned it to fed36m-audio (that way I keep a pristine copy of the template around). I deactivated the cacher.

I then ran this salt script:

tmpl-{{namestem}}-base-update:
        cmd.run:
        - name: 'sudo dnf update'

tmpl-{{namestem}}-installs:
    pkg.installed:
    - install_recommends: True
    - pkgs:
        - qubes-core-agent-passwordless-root
        - alsa-plugins-pulseaudio
        - alsa-utils
        - pulseaudio-utils
        - pipewire-utils
        - webrtc-audio-processing
        - xfce4-pulseaudio-plugin
        - pavucontrol
        - pulseaudio-module-bluetooth
        - pulseaudio-qubes
        - qubes-core-admin-client
        - pciutils

tmpl-{{namestem}}-daemon:
    pkg.installed:
    - install_recommends: True
    - pkgs:
        - qubes-audio-daemon

And…the SAME result. Sound goes into sys-audio…nothing comes out of the speakers. Pavucontrol shows bouncing sound levels like it’s getting the signal from the source VM, and sending it on, but again, it doesn’t seem to see the output device.

sudo lspci -k -v result is that it finds the controller, as before

aplay -l no soundcards found...

qvm-start-daemon --all --watch tells me another GUI daemon process is already running.

First things first…am I forgetting something that needed to go into the template?

Not that I’m aware of.

Why don’t you diff dom0 and audio template with meld?

Export both list, put them somewhere where Meld is installed, and it would show you if some package is missing:

$ sudo dnf repoquery --qf ‘%{name}’ --installed | grep -v – ‘-debuginfo$’ | grep -v ‘^(kernel-modules|kernel|kernel-core|kernel-devel)$’ > pkgs_a.lst

But I still suspect on alsa-sof as said above…

You can’t even imagine what I’ve been through in order to be able to pasthrough audio device to sys-audio…

OK let me pursue alsa-sof. Except that I have no idea what to do. I simply didn’t understand the post you quoted on that.

Do I do a dnf-remove on something? doing a dnf list installed on template and dom0 shows it is on dom0 not the template. Am I supposed to install something else in its place? Or do something on the template?

As I said, this is purely guessing on that. So, if alsa-sof-firmware is installed in dom- and not in the template, then I’d install it in a template if it’s not there too, and vice versa.

Then I’d run those two commands in template (modprobe - r... and modprobe....

On a github link above I noticed the message from 8 days ago

Just an update, that the fixes pull request was merged into Linux 6.1-rc5, so the commit is in Linus’ master branch.
The two qcom commits were already backported to the stable series (at least contains them 6.0.9), so maybe somebody needs to ask for a stable backport for the commit at hand?

OK, adding it to the template makes sense…I don’t know how I got the impression you thought it should be removed from dom0.

However…doing so didn’t actually help.

modprobe…well, that mucks with the kernel and I am really am way outside my knowledge doing that. I have no idea what parameters to put into those two commands.