It is a regression, the issue seems to be that the pulseaudio version used in the stubdom is too old compared to the stubdom kernel.
The pulseaudio process crash in the stubdom
Some relevant logs here:
(no issue with the domid, the value is correct)
[2025-11-02 07:32:52] + pulseaudio '--use-pid-file=no' '--daemonize=no' '--exit-idle-time=-1' -n -L 'module-native-protocol-unix auth-anonymous=1 socket=/tmp/pa.sock' -L 'module-vchan-sink domid=1'
[2025-11-02 07:32:52] pulseaudio[55]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
[2025-11-02 07:32:52] W: [pulseaudio] authkey.c: .[1mFailed to open cookie file '/tmp/pulse/cookie': No such file or directory.[0m
[2025-11-02 07:32:52] W: [pulseaudio] authkey.c: .[1mFailed to load authentication key '/tmp/pulse/cookie': No such file or directory.[0m
[2025-11-02 07:32:52] W: [pulseaudio] authkey.c: .[1mFailed to open cookie file '//.pulse-cookie': No such file or directory.[0m
[2025-11-02 07:32:52] W: [pulseaudio] authkey.c: .[1mFailed to load authentication key '//.pulse-cookie': No such file or directory.[0m
[2025-11-02 07:32:52] E: [pulseaudio] module-vchan-sink.c: .[1;31mvchan module loading.[0m
[2025-11-02 07:32:52] E: [pulseaudio] module-vchan-sink.c: .[1;31musing domid: 0.[0m
[2025-11-02 07:32:52] E: [pulseaudio] module-vchan-sink.c: .[1;31mplay libvchan_fd_for_select=14, ctrl=0x561ea70b2d60.[0m
[2025-11-02 07:32:52] E: [pulseaudio] module-vchan-sink.c: .[1;31mrec libvchan_fd_for_select=22, ctrl=0x561ea70b3790.[0m
[2025-11-02 07:32:52] E: [vchan-sink] module-vchan-sink.c: .[1;31msink cork req state =1, now state=-2.[0m
[2025-11-02 07:32:52] E: [vchan-sink] module-vchan-sink.c: .[1;31msource cork req state =1, now state=-2.[0m
This error:
memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
is directly related to having a kernel too recent for the pulseaudio version (warning / restriction have been imposed by the kernel on memfd_create that the current version of pulseaudio donāt respect yet. More recent version of pulseaudio respect it)
If someone is motivated, create a github issue / try to write a pull request
Seems like the error is in the policy file, some event got added (I havenāt found which one yet), and are required to properly handle non linux hvm.
As a workaround, adding
I have modified the policy file to include those values, and this has indeed resolved the issue.
journalctl now emits a different warning when starting any qube with sys-audio as its audiovm (listed below), but at least on a first test run everything seems to be working fine nevertheless.
dom0 qrexec-policy-daemon[2870]: qrexec: admin.vm.feature.CheckWithTemplate+gui: sys-audio -> win10: denied: no matching rule found
dom0 qrexec-policy-daemon[2870]: qrexec: admin.vm.feature.CheckWithTemplate+gui: sys-audio -> disp1451: denied: no matching rule found
I will report back if I find out what the above error means in practice.
Thank you again for the help and for the detailed guide!
I gave up on having audio. My USB device only connects to sys-usb, so I canāt make a persistent audioVM, I tried to transform sys-usb into an audioVM, I tried everything to change the template of the sys-usb, install packages, add policies to dom0, all of it, nothing works.
I would only touch this again if a step by step guide specifically for this setup and qubes version with all instructions needed, nothing skipped or assumed, appeared. Sadly I donāt think one would ever appear.
You canāt have usb sound without sys-usb running first.
So either attach this usb sound device to sys-audio and start sys-audio manually or every start attach usb sound device.