Using sys-audio for Windows audio

User Support General
5

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

6

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.

1 Like
7

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.

3 Likes
8

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?

9

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
10

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.

11

Thanks for details and testing!

2 Likes
12

@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.

13

@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.

14

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.

15

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

16

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

17

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.

18

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:

audio_domid=0
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)
fi
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 ?

19

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.

20

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

21

Ah indeed. I’ve also tried that, it works in dom0 but doesn’t seem to be working in stubdom.

audio_domid=$(xenstore-ls -f | grep -oP '(?<=domain/)[0-9]+(?=/name = \"sys-audio\")')
22

I managed to find a very messy way of doing it:
cp /etc/libvirt/libxl/<nameofwindowsvm>.xml /etc/qubes/templates/libvirt/xen/by-name/

vim /etc/qubes/templates/libvirt/xen/by-name/<nameofwindowsvm>.xml (look for cmdline and add what I did after the netmask netmask=255.255.255.255,-qubes-audio:domid=1)

Now in stubdom:

audio_domid=0
vm_name=$(xenstore-read "/local/domain/$domid/name")
if [ $(echo "$vm_name" | grep -iEc '^windows') -eq 1 ]; then
    audio_domid=$(echo "$dm_args" | grep -oE 'qubes-audio:domid=[0-9]+' | grep -oE '[0-9]+')
fi
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" &

Now let’s create a libvirt hook that changes the value of the domid in the xml file to the correct one (the hook gets triggered every time sys-audio starts):
/etc/libvirt/hooks/libxl

#!/bin/bash
guest_name="$1"
libvirt_operation="$2"
 
if [ "$libvirt_operation" = "started" ]; then
    (
        exec 0</dev/null
        exec 1>/dev/null
        exec 2>/dev/null
        if [ $(qvm-prefs $guest_name name) = "sys-audio" ]; then
            sed -i 's/\(qubes-audio:domid=\)[0-9.]\+/\1'$(qvm-prefs sys-audio xid)'/' /etc/qubes/templates/libvirt/xen/by-name/<nameofwindowsvm>.xml
        fi
    ) & disown
fi

chmod +x /etc/libvirt/hooks/libxl

That’s it. Hopefully someone comes with a cleaner solution soon.

1 Like
23

I don’t know if there’s any benefit but I personally use dispVM’s for everything besides sys-whonix, and yes if the template gets compromised the dispVM will be too.

24

While I know for sure it worked at the end of March, in May not sure, but today for sure I can’t extract stubdom

[user@dom0 stubdom-full]$ cpio -i -d -H newc --no-absolute-filenames < qemu-stubdom-linux-full-rootfs rm qemu-stubdom-linux-full-rootfs
64471 blocks

This is the only I got, command and the output are copy/pasted from dom0. Do you have any idea what might be wrong?

I can extract it with Ark with the whole structure, then edit init, then recreate it back with cpio/gzip, but then win qube won’t start with error in libxl-driver.log

2022-09-25 18:08:39.427+0000: libxl: libxl_dm.c:1975:libxl__build_device_model_args_new: Domain 27:Only 4 emulated IDE disks are supported.
Disk xvdi will be available via PV drivers but not as an emulated disk.
2022-09-25 18:09:19.848+0000: libxl: libxl_dm.c:2800:stubdom_xswait_cb: Domain 27:Stubdom 28 for 27 startup: startup timed out
2022-09-25 18:09:19.848+0000: libxl: libxl_create.c:1913:domcreate_devmodel_started: Domain 27:device model did not start: -9
2022-09-25 18:09:20.646+0000: libxl: libxl_device.c:1146:device_backend_callback: Domain 28:unable to remove device with path /local/domain/7/backend/vif/28/0
2022-09-25 18:09:22.494+0000: libxl: libxl_domain.c:1553:devices_destroy_cb: Domain 28:libxl__devices_destroy failed

Does cpio works for you and will your win qube start with init edited?

If I put original stubdomain back, win qube works well, but without audio since I can’t patch it successfully…