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.
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
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.
@neowutran Is there any way to make this solution compatible with switching keyboard layouts on 4.2? If audiovm enabled I need to press switch shortcut multiple times for the layout to switch. Imagine the frustration during writing something when you need to switch layouts multiple time or sometimes it takes a huge delay to switch.
Layout switches in dom0 just fine, but I guess something is wrong with RPC policies because audiovm just suppresses some layout change events for some reason.
I understand, but could you please consider testing it on your end and seeing if it works? That is not really a niche case and your guide is the best I could find.
I also tried to allow property get and set on +keyboard_layout, but the issue still persists making using a keyboard on qubes with audiovm enabled almost unbearable.
The only solution for me after multiple hours of tinkering was to return to dom0 hdmi audio and ask for help.
I see this patch is still pending, was it ever sent as a PR? Or is there something blocking it being added officially? This guide has been helping many people for a long time so it would be nice to make it easier for more people to use.