Delete all thoses “stubroot” folder and run the script only once.
( You probably tried to run it 3 times. (mkdir stubroot … cd stubroot … mkdir stubroot … ).
Also, show xen.xml file, it need to be modified
Thanks for the great guide!
Can an audio vm be reverted by just typing qubes-prefs default_audiovm dom0 (or qvm-prefs qube audiovm respectivelly) and deleting audio policies, not using patched version?
It’s been on my todo list for months now, and I don’t have a testing system atm.
Also: Do you know good resources to read more about audio security?
- How relevant is this in practice?
- What vulnerabilities does
dom0have in terms of audio, when using no audio qube? - Does
pulseaudio-qubes/pipewire-qubesdo some sort of sanitizing and filtering, before forwarding the audio stream todom0?
Can an audio vm be reverted by just typing
qubes-prefs default_audiovm dom0(orqvm-prefs qube audiovmrespectivelly)
Yes, you can configure each qubes to use your preferred audiovm.
Also: Do you know good resources to read more about audio security?
If dom0 get owned, you loose everything. So you want dom0 to be as small as possible. So ideally, dom0 should only be here to manage the qubes, and nothing else. ( So for specifically, audio, you don’t want dom0 to handle USB devices, bluetooth systems, etc… )
Does
pulseaudio-qubes/pipewire-qubesdo some sort of sanitizing and filtering, before forwarding the audio stream todom0
1 Like
Appreciated - somehow I missed that linked article.
It seems that to get the mic that is handled by the sound card to be assignable to other qubes, the following Python code needs to be modified. dom0: /usr/lib/python3.11/site-packages/qubesguidaemon/mic.py It contains comments that indicate it is currently coded to assume dom0 audiovm. But, it looks like it is structured to be able to enumerate multiple mics. I am not knowledgeable enough in Python or the Qubes API to attempt this.
Now I feel stupid. After using the qusal tools I have a functioning disposable audio qube and the mic is assignable. So please disregard my previous post.
1 Like
When starting sys-audio I get the error Denied: admin.vm.list form sys-audio to dom0
I can use the aplay Noise.wav command to play noise on sys-audio but audio doesn’t work on other vms
I get an error in the sys audio terminal when executing qvm-start-daemon --all --watch
this error seems to indicate an error in the policy file “50-sys-audio.policy”, can you paste your policy file ?
Here you go. I tried to paste directly from you poist but maybe it got messed up in transport. I even gave it 777 permissions as well as the qvm_start_daemon.py hoping it would help.
Update: I see its blank sorry here is the new one.
50-sys-audio.log (1.6 KB)
Well, if the policy file is empty, that is indeed the issue
Its working now thank you 
with the last update now its broken, i have this problem
qrexec-policy-agent
denied: admin.vm.property.GetAll
denied admin.vm.property.GetAll from sys-audio to sys-audio
well i fixed this problem editing the policy file and adding this:
admin.vm.property.GetAll * sys-audio @tag:audiovm-sys-audio allow target=dom0
it dont make me confortable using * its possible to limit it?
well i fixed this problem editing the policy file and adding this:
admin.vm.property.GetAll * sys-audio @tag:audiovm-sys-audio allow target=dom0it dont make me confortable using * its possible to limit it?
Yes, the recent update replaced ‘qvm_start_daemon.py’ in our audio-template qube. All you have to do is reapply the patch to the template and audio should work again. Let me know if you run into any trouble reverting back to the recommended way.
With many thanks to @neowutran for the awesome guide. I would like to add few of my personal Tweaks:
If you are not happy about the error while trying to turn of sys-audio when no other VM is using it
sys-audio: Shutdown error: There are running VMs using this VM as AudioVM: sys-audio:
You could modify /usr/lib/python3.11/site-packages/qubes/ext/audio.py (originally a part of qubes-core-admin repository) and change attached_vms method of AUDIO class line 29-30 from:
In 4.2
if getattr(domain, 'audiovm', None) and domain.audiovm == vm:
yield domain
to
if getattr(domain, 'audiovm', None) and domain.audiovm == vm \
and domain != vm:
yield domain
Reboot. Problem solved. I personally use the below workaround since I find it more elegant.
My favourite workaround is to set audiovm pref of sys-audio to dom0 in case dom0 provides PCI Audio Interface to it and to sys-usb if sys-usb provides an external USB audio interface to it. As it is the logical way to set the dependencies.
qvm-prefs sys-audio audiovm dom0
if you want your new sys-audio interface to appear in SERVICE tab of the Appmenu
Check the Provides Network in the Advanced Settings of sys-audio. Then add the following services in Services Tab: network-manager, qubes-firewall, qubes-network, qubes-updates-proxy and qubes-update-check. Finally un-check them all to be like this:
The above dirty hack is a workaround of the well known bug of Qubes resetting servicevm feature of VMs after each reboot based on provides_network pref of VMs. But it works well in the end:
Consideration for DAW users who want to use Qubes for any reason
Since Qubes inner-vm Audio Virtualisation is currently only 44.1KHz 16bit Stereo Sink/Source (Audio CD-Quality from Early 90s) and it is highly unlikely for it to receive anything better than 48KHz 16bit Stereo, you can not rely on Qubes inner VM Audio Virtualisation for your main line of work. But you can use the guide provided on the beginning of the thread with minor tweaks to have an independent DAW qube which might act as sys-audio as well for studio monitoring purposes. Just skip the disposable template part. Use XFCE templates for DAW qube. Install Ardour/LMMS/Reaper/… in that template. Allocate tones of RAM (4 or 6GB) and a couple of cores to sys-audio. And do your DAW work inside it. The DAW+sys-audio qube will not be as safe and secure as the disposable sys-audio. But it will have some security benefits. E.g. it could be network-less. And there is always physical gain knob and Phantom power switch to turn-off the input.
2 Likes
Hello, thanks for the instructions. I am new to qubes os and tried to follow all steps. Everything works and looks the same until i want to start sys-audio for testing sound. My sys-audio qube is just not starting. Under qubes domains it shows sys-audio in red colour, like other qubes when starting, but it never get started.
do you have an idea what could be the issue?
i also don´t know which kind of log would be helpful for the solution
1 Like
What devices did you attach to your sys-audio?
You can run this command in dom0 terminal:
journalctl -f -n0
Then start sys-audio and check the command output in dom0 terminal to see the errors.
You can copy from dom0 to other qubes like this:
How to copy from dom0 | Qubes OS
If anyone for any reason has decided to avoid a dedicated template for sys-audio and installed pasystray or volumeicon in the template, you will end up with multiple volume controls in systray per each VM based on that template. Something similar to the bug Marek reported 2 days ago:
Only the one which belongs to sys-audio is useful and the rest are useless. These systray volume controls are automatically launched via:
for pasystray: /etc/xdg/autostart/pasystray.desktop
for volumecontrol: /etc/xdg/autostart/volumeicon.desktop
There are multiple workarounds to solve the issue. One would be adding a Hidden=true to those .desktop files in /etc/xdg/autostart and copy the original desktop files without hidden tag to /home/user/.config/autostart of sys-audio. The disadvantage of this method is that it is going to be overwritten in template whenever pasystray (or volumeicon) receives and update.
The other workaround would be to have the .desktop with Hidden=true tag in /home/user/.config/autiostart of all AppVMs based on template (and the template itself so the new AppVMs would inherite it). But not inside sys-audio.
4 Likes
You still can shut down audio qube via audio qube’s terminal. Also @cumpsd.
1 Like
My sys-audio also doesn’t boot on start. Have you found a solution?