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…