It’s me again, and probably with a stupid question, but i just don’t know how to solve it.
After the last problem i followed all steps, the test sounds works. after sys-audio has started, the next qube starting shows an error
Blockquote
Denied: admin.vm.property.GetAll
In the guide it says that some files need to be patched, in one of it, there is a comment with:
Don’t use GetAll qubes policy request for audiovm
I just do not know how i don’t use GetAll - since this is the problem, i guess.
maybe someone can help me?
thanks a lot in advance for help
Followed the new tutorial and still can’t get it to work properly. The audio works in the sys-audio qube just fine, but doesn’t work in any other qube. Still can’t figure out what I’m doing wrong or whether it has something to do with my hardware.
Edit: Since only sys-audio works, I created a dedicated qube for audio which works out fine.
Hi again. I’ve not been able to make the sys-audio thing to work using a fedora template so I’ve repeated the process from scratch but now using a debian-12 template. The result is not yet good enough but I’ve made some progress. Currently I can attach an appVM to sys-audio via qvm-prefs command and get audio working in that appVM but something is wrong with the hardware detection. I have two audio cards, attached to sys-audio:
$ qvm-device pci ls sys-audio
BACKEND:DEVID DESCRIPTION USED BY
dom0:00_1f.3 Audio device: Intel Corporation Comet Lake PCH cAVS sys-audio (no-strict-reset=True)
dom0:01_00.1 Audio device: NVIDIA Corporation sys-audio (no-strict-reset=True)
When I run pavucontrol in the appVM I see no audio cards in the configuration tab, the only input device is Qubes Virtual Audio Source and the only output device is Qubes Virtual Audio Sink. Running alsamixer, the sound cards are not detected.
In sys-audio pavucontrol starts but works badly (I cannot move from one tab to a different one). Running alsmixer both sound cards are detected.
Well, I don’t understand what happened yesterday but today everything works just fine . It seems I made too many changes and the system had to be restarted.
Like, it is very slow ? does sys-audio consume a lot of CPU or anything similar ?
No, no very slow. Simply non responsive, It was stuck in the Playback tab and I was totally unable to change to a different one. I don’t know about CPU usage cause I cannot reproduce the problem.
Anyway, thanks a lot for your great guide and for your valuable help.
I just started using bluetooth (because now I can, thanks!), but I cannot figure out why cairo-dock is listed as required for bluetooth. This is an application dock, like on MacOS. I have also removed it and used bluetooth with no difference.
On another note, I’m pretty sure that with pipewire, the libspa-0.2-bluetooth is required. Mine wouldn’t connect and gave a “br-connection-profile-unavailable” error, and I diagnosed it to be this package that was necessary, and installing it fixed everything. Given my inexperience, I’ll wait for confirmation, but if someone will confirm I’ll add it to the guide.
i notice after some time it becomes out of sync, music kind of “stutters”/glitches?
its especially noticeable with USB headset listening to SIP phone clients (lin phone), audio is scrambled and delayed. even more when system was suspended.
is there a way to get it back to sync? right now i restart my system once a day as mitigation and it works most of the time till the evening…
Note, I should edit the guide to go back to patching the source code: Sys-audio drops qubes on restart - #2 by neowutran
Should also open a github issue ticket to better understand this issue, I expect it to be a cache issue.
in the attached screenshot the sys-usb has patched the bluetooth card with a bluetooth speaker connected to sys-audio and i listen to nts.live (internet radio) in a firefox (“socialmedia” vm) when everything works. (is “in sync”)
You always had this issue, or is it something recent ?
if you don’t open pavucontrol, do you still have the same issue ?
Can you try that : ?
Audio is scratchy [Need someone to comment if this is still usefull]
It may be a power-saving issue with the sound card.
In the “audio-template” and/or "dom0", create the file ‘/etc/modprobe.d/50-snd.conf’ with the following content:
options snd_hda_intel power_save=0
And can you try to apply that too ? :
And maybe check “dmesg” and “journalctl -xe” in dom0 & sys-audio to see if you find some idea/suspicious things
thanks for the leads where to find logs and mitigation options, i will try them all.
but yesterday there were a lot of updates from qubes and fedora repos, and today there is no occurrence of said behavior. i am optimistic and will put the laptop to sleep and see were i will be tomorrow.
Switching keyboard layouts becomes terribly unreliable after following this tutorial.
Maybe there’s something wrong with the policies, maybe it somehow severely restricts the important things? I don’t even need to set sys-audio as the default audiovm in dom0 to get this unpleasant side effect.
Just create a qube named sys-audio, enable the audiovm service in settings and set those policies from the guide. Once the qube is started, the delicate universal balance will be disturbed and the user’s mental health will be jeopardized after every attempt to change the layout while writing. Sometimes it changes, sometimes it doesn’t, sometimes with a delay - unreliable.
And dom0 accurately records the fact of changing the layout. This is very easy to understand if you enable the ‘Keyboard layouts’ widget on the xfce panel - it always visually changes the layout correctly after clicking on the widget/key combination. It’s in the qube itself that can’t realize that the layout has changed. ‘/usr/bin/qubesdb-read /keyboard-layout’ in appvm doesn’t always display what dom0 displays.
ok on my end the problem now seems to be linphone (sip client app) specific
read more... (not relevant)
all other audio either from jitsi via chromium in the same VM to the same usb *via sys-audio with sys-usb connected headphone is still “normal”
and other VMs still have regular audio to bluetooth connector.
even after suspend audio works regular again, although i had to restart the VMs because sys-audio lost audio completly (maybe pci device missing, didnt check yet…)
as far as i can remember i sometimes had issues with linphone before and just rebooted the VM because at the time i connected the USB headset via sys-usb directly to the VM… but since there is no usb involved anymore and even with the laptop speakers i get the same distorted sound and up to 8 second delay i guess linphone is just the cause
if you have recommentdations for sip client application i much welcome it, linphone also has this stupid overlay which lets you click on answering a call, but the overlay sometimes isnt clickable…
systemctl --user restart pipewire (and pipewire-pulse in not yet determined order) fixed this issue too, noice
Thanks for correlating this - I was having the same problems with keyboard layout changes recently and didn’t know what was causing it, but the timeline would make sense if it’s since I introduced sys-audio.