Audio qube

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.

How can I fix those problems? TIA

(I cannot move from one tab to a different one).

Like, it is very slow ? does sys-audio consume a lot of CPU or anything similar ?

In the “configuring policy” part of the guide, in the “recommended way” there is a patch for the file “qvm_start_daemon.py” that solve this issue

1 Like

Well, I don’t understand what happened yesterday but today everything works just fine :sweat_smile:. 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.

1 Like

Simplified the “configuring policy” part based on this discussion: Monitor and update keyboard layout only if the qube asked to be a guivm by neowutran · Pull Request #237 · QubesOS/qubes-core-admin-client · GitHub

2 Likes

Thanks a lot for answering all question - finally it works how expected!

1 Like

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.

It was required for bluetooth to work with pipewire in debian-12-minimal:

1 Like

I’ll go ahead and change the dock, and I’ll add a note for debian-12-minimal for the other package.

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.

For the issue mentionned by @ymy and here: [sys-audio] Audio cutting in and out making audio unusable
If you can, try to check the cpu consumption of sys-audio and dom0, run “top” and check what are some of the most CPU hungry process.

Don’t have much time currently to do that properly, I have the new FFXIV extension to farm :sweat_smile:

5 Likes

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”)

Screenshot (click)

when i have the same behavior i will do another screenshot

1 Like

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

1 Like

I think there could be some useful info in ~/.xsession-errors in sys-audio and in the test qube as well.

1 Like

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. :slight_smile:

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.

2 Likes

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 :frowning:

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 :smiley:

1 Like

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.

Shutting down sys-audio doesn’t help, though.

1 Like