Audio qube

Community Guides
401

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

(note: tested in R4.3)

Created an issue [R4.3] pulseaudio process crashing in stubdom for Windows VM ¡ Issue #10379 ¡ QubesOS/qubes-issues ¡ GitHub

1 Like
402

nvm

403

Good to know, thank you very much for your work debugging the error!

404

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

admin.Events          *                      sys-audio     @tag:audiovm-sys-audio    allow target=dom0
admin.vm.property.Get               +virt_mode                      sys-audio     @tag:audiovm-sys-audio    allow target=dom0

should solve the issue.
But I prefer to find the exact event required before modifying this guide

1 Like
405

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!

406

After a week of testing, everything seems to be working well regardless of the denial notifications that happen for every qube.

I noticed a slightly different error message also appears when connecting an external audio device through USB with the modified policy:

dom0 qrexec-policy-daemon[2940]: qrexec: admin.vm.property.GetAll: sys-audio -> personal: denied: denied by policy /etc/qubes/policy.d/50-sys-audio.policy:31
dom0 qrexec-policy-daemon[2940]: qrexec: admin.vm.property.GetAll: sys-audio -> win10: denied: denied by policy /etc/qubes/policy.d/50-sys-audio.policy:31

50-sys-audio.policy, line 31 corresponds to:

admin.vm.property.GetAll *                                        sys-audio   @tag:audiovm-sys-audio      deny notify=no

Nevertheless, the USB audio device works correctly, so it does not constitute an issue on my end.

407

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.

408

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.

409

Updated the guide with the correct minimum policy

2 Likes
410

Thanks for the heads up!

Just ran a quick test after applying the new policy.

After the update, audio in the Windows HVM unfortunately no longer works, nor does the sink appear in the sys-audio control.

journalctl log below:

dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.feature.CheckWithTemplate+gui: sys-audio -> win10: denied: no matching rule found
[...]
dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.property.Get+xid: sys-audio -> win10: allowed to dom0
dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.property.Get+stubdom_xid: sys-audio -> win10: allowed to dom0
dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.feature.CheckWithTemplate+audio: sys-audio -> win10: allowed to dom0
dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.feature.CheckWithTemplate+audio-model: sys-audio -> win10: allowed to dom0
dom0 qrexec-policy-daemon[2778]: qrexec: admin.vm.property.Get+virt_mode: sys-audio -> win10: denied: no matching rule found
dom0 qrexec-policy-daemon[2778]: qrexec: qubes.NotifyTools+: untrusted-win10 -> @adminvm: allowed to dom0

After adding the virt_mode line from the previous fix back into the new policy, audio functions correctly again.

admin.vm.property.Get               +virt_mode                  sys-audio	@tag:audiovm-sys-audio	  allow target=dom0

As per the previous report, the “CheckWithTemplate+gui” error notification still appears constantly, though the error that appeared when connecting an external usb device seems to no longer be present.

In either case, it does not seem to affect functionality.

1 Like
411

I passthrough my bluetooth controller on this sys-audio. I went for an AppVM with the /var/lib/bluetooth bind dir so that the device configuration is retained.

What’s the benefit of the disposable template vs regular AppVM?

412

So that if a Disposable gets compromised, it will be clean again after its restart?

3 Likes
413

Hi,

Im running

qvm-start-daemon --all --watch

In my sys-usb, and get error:

<some fedora 42 xfce based qube>: Starting AUDIO
asyncio: Task exception was never retrieved
future: <Task finished name='Task-4' coro=<DAEMONLauncher.start_audio() done, defined at /usr/lib/python3.13/site-packages/qubesadmin/tools/qvm_start_daemon.py:623> exception=TypeError('expected str, bytes or os.PathLike object, not int')>
Traceback (most recent call last):
  File "/usr/lib/python3.13/site-packages/qubesadmin/tools/qvm_start_daemon.py", line 640, in start_audio
    await self.start_audio_for_vm(vm)
  File "/usr/lib/python3.13/site-packages/qubesadmin/tools/qvm_start_daemon.py", line 597, in start_audio_for_vm
    await asyncio.create_subprocess_exec(*pacat_cmd)
  File "/usr/lib64/python3.13/asyncio/subprocess.py", line 224, in create_subprocess_exec
    transport, protocol = await loop.subprocess_exec(
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        stderr=stderr, **kwds)
        ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/asyncio/base_events.py", line 1802, in subprocess_exec
    transport = await self._make_subprocess_transport(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        protocol, popen_args, False, stdin, stdout, stderr,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        bufsize, **kwargs)
        ^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/asyncio/unix_events.py", line 213, in _make_subprocess_transport
    transp = _UnixSubprocessTransport(self, protocol, args, shell,
                                    stdin, stdout, stderr, bufsize,
                                    waiter=waiter, extra=extra,
                                    **kwargs)
  File "/usr/lib64/python3.13/asyncio/base_subprocess.py", line 40, in __init__
    self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                stderr=stderr, bufsize=bufsize, **kwargs)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/asyncio/unix_events.py", line 855, in _start
    self._proc = subprocess.Popen(
                 ~~~~~~~~~~~~~~~~^
        args, shell=shell, stdin=stdin, stdout=stdout, stderr=stderr,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        universal_newlines=False, bufsize=bufsize, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/subprocess.py", line 1039, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        pass_fds, cwd, env,
                        ^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
                        gid, gids, uid, umask,
                        ^^^^^^^^^^^^^^^^^^^^^^
                        start_new_session, process_group)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/subprocess.py", line 1876, in _execute_child
    self._posix_spawn(args, executable, env, restore_signals, close_fds,
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      p2cread, p2cwrite,
                      ^^^^^^^^^^^^^^^^^^
                      c2pread, c2pwrite,
                      ^^^^^^^^^^^^^^^^^^
                      errread, errwrite)
                      ^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/subprocess.py", line 1820, in _posix_spawn
    self.pid = os.posix_spawn(executable, args, env, **kwargs)
               ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: expected str, bytes or os.PathLike object, not int

Audio from vms for some reason is not reaching sys-usb
If I attach my usb sound device to vm, vm produce sound properly.

Ive upgraded to 4.3 from 4.2, and before it Ive upgraded from 4.1 =)

Any recommendations on where to start digging?

I think I will start dedicated thread Fixing audio after update

414

I thought I’d add here a post I made, about an issue I have with my microphone after updating to 4.3, since I haven’t gotten any responses there.

Please let me know if you are aware of any changes in 4.3, that breaks functionality in this guide.

415

I also get this error notification displayed after starting any qube.
Denied: admin.vm.feature.CheckWithTemplate+gui

2 Likes
416

This should be a Qubes Policy issue. In your audio policy you can add,
admin.vm.feature.CheckWithTemplate +gui sys-audio @tag:audiovm-sys-audio allow target=dom0

You shouldn’t see this error anymore afterwards.

2 Likes
417

Thanks.

@neowutran could you add this to the first post?

418

I can’t reproduce right now, will retry later. Can you check if this policy also solve this issue ?

admin.vm.feature.CheckWithTemplate +gui sys-audio @tag:audiovm-sys-audio deny notify=no

If it work it doesn’t display the error message instead of giving an unneeded privilege

1 Like
419

Just gave it a quick test on my end, and it indeed seems to work as expected to resolve the issue.

420

This should work, but you need to add target=dom0.