Using sys-audio for Windows audio

Audio works fine with dom0 as the audiovm using the audio-model feature, however it doesn’t with sys-audio as the audiovm.

pacat-simple-vchan does autostart but keeps the same state when I shutdown Windows. When I try to attach the mic to Windows it says “pulseaudio agent not running”.

Has anyone got it working? (I’m using sys-audio for all other qubes)

Hello. Did you search forum for it? It is unresolved issue so far, at least for me.

I have, I searched everywhere your thread was the only relevant result I found.

Obviously no interesting in the matter at the moment, and perhaps you should post there and not to open new topic.
@jevank is maintainimg this and he’s aware of it.

I agree, I failed to follow the forum rules. I’m sorry, it won’t happen again.

Sorry, my English is not my first language. It was a suggestion that complies with the rules. I am just a user as you, eager to make it working just as you.

I patched qemu-stubdom-linux-full-rootfs and changed the domid of module-vchan-sink from 0 to the xid of sys-audio, this is more of a workaround than a solution but at least I have working audio on Windows.


That is great and it would be great if you could share step by step how to patch it so others could benefit from it as well?

Sure, However I did the bare amount of changes to make it work, keep in mind that this will change the behaviour of all qubes using qemu-stubdom-linux-full-rootfs, not only Windows, you’ll only be able to use sys-audio as the audiovm for those qubes.

If despite all the flaws anyone wants to try this: (Remember to keep a copy of qemu-stubdom-linux-full-rootfs in case you want to easily revert the changes)

mkdir /tmp/stubdom-full
cd /tmp/stubdom-full
cp /usr/libexec/xen/boot/qemu-stubdom-linux-full-rootfs qemu-stubdom-linux-full-rootfs.gz
gunzip qemu-stubdom-linux-full-rootfs.gz
cpio -i -d -H newc --no-absolute-filenames < qemu-stubdom-linux-full-rootfs
rm qemu-stubdom-linux-full-rootfs
vim init (Using your text editor of choice find module-vchank-sink and change the value of domid from 0 to the xid of sys-audio, you can find the xid using qvm-prefs sys-audio | grep -w xid, after that save and exit)
find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../qemu-stubdom-linux-full-rootfs
cp ../qemu-stubdom-linux-full-rootfs /usr/libexec/xen/boot/qemu-stubdom-linux-full-rootfs

Now you should be able to have sound using sys-audio as your audiovm for Windows, if not let me know.

1 Like

So, after testing I can confirm that the patch works. Thank you @disp584!

What I can say about the sound is:

  • The patch didn’t affect non-win qubes as I can tell. I had already set sys-audio as default_audiovm for all VMs in order to be able to use sound in disposables (I don’t know any other way to achieve this), and then manually set VMs not to have audio (templates, netVMs, some sys*VMs, vault, etc…) and this setting remained after this patch. But, it seems I had to reapply ...audiovm sys-audio for win qubes! I know this because in my quoted topic I have already stated that qvm-tags ouptut sys-audio as audiovm, but after this patch I didn’t have this tag, so as I said I reapplied default audioVM and had to do that for all win qubes.
  • Sound is not that clear like in dom0. But, that remark is for sys-audio in general, not exclusively related to win qubes.
  • As I hopefully suspected, sound in sys-audio is much, much less choppy then in dom0 and these are great news! It’s almost fluent!

What is your experience with this?

Since the patch is trivial, I’ll tag @jevank, and I hope he’ll get us an update soon.

Thanks for details and testing!


@enmus I also had to reapply ...audiovm sys-audio, I forgot to mention that. Personally I don’t notice a difference in sound quality between sys-audio and dom0, as for manual setting most VMs to not have audio you can use qubes-prefs default_audiovm '' to set the default audiovm to None.

@jevank Do you know if it’s currently possible to do what marmarek mentioned with the current implemention? If it is would you mind sharing what arguments should be added to qemu’s cmdline, thank you.

The proposed variant looks not difficult to implement, but it involves several components and needs to be tested. I’m thinking about doing this, but I’m not ready to say when. All the more, your workaround with stubdomain patch is quite workable and stubdomain is not updated often.

Well, after updating xen-hvm-stubdom-linux-full, whole patching procedure must be reapplied.

That’s normal. Also if you use sys-audio as a dispvm the xid won’t always be the same

There’s a typo in the post and I can’t edit it:

Using your text editor of choice find module-vchank-sink and change the value of domid from 0 to the xid of sys-audio

The parameter to edit for whoever is looking to this is module-vchan-sink not module-vchank-sink.

That’s normal. Also if you use sys-audio as a dispvm the xid won’t always be the same

I am trying to do something like that but no luck:

vm_name=$(xenstore-read "/local/domain/$domid/name")
if [ $(echo "$vm_name" | grep -iEc '^windows' ) -eq 1 ]; then
   audio_domid=$(qvm-prefs sys-audio | grep -w xid | tr -s ' ' | cut -d' ' -f3)
pulseaudio --use-pid-file=no --daemonize=no --exit-idle-time=-1 --disable-shm=yes -n \
    -L "module-native-protocol-unix auth-anonymous=1 socket=/tmp/pa.sock" \
    -L "module-vchan-sink domid=$audio_domid" &

Anyone seeing why that wouldn’t work ?

Is there a reason to use sys-audio as dispVM, beside side-channel attacks? It’s offline, no (extra) apps running in it except terminal and file manager (the latter very rarely), it anyway depends on template so if the template is compromised (unlikely) then dispVM will be too…?
For my use case, sys-audio AppVM is safer to use then vault, since I at least use KeePass in a vault which is AppVM too.

That’s because qvm-prefs isn’t present in stubdom, the same result can be achieved with xenstore-list, xenstore-read or xenstore-ls. It should be rather easy but I’m not familiar with bash scripting, whenever I happen to get it done I’ll make sure to post it.

Update: I take back saying the same result can be achieved with the xenstore utilities. Perhaps @tzwcfq could shed some light on us