Audio support for Windows

[omeg]

Add audio support for Windows HVMs (probably try an already supported emulated audio hardware and use pulseaudio for streaming?)

[demianrihs]

Hello, any news on this? I am trying to achieve this using PCI Passthrough of the soundcard. But I am getting following error:

PCI device 0000:00:1f:3: no FLR, PM reset or bus reset available

[DemiMarie]

This should be doable by using standard Qubes audio in the stubdomain, and telling qemu to emulate audio hardware that Windows is known to support.

[SvenSemmler]

Until then ... this did the trick for me: https://www.amazon.com/gp/product/B07L56C28R It's a USB Audio dongle and you can plugin in any headphone/mic or speaker you like.

[marmarek]

This should be doable by using standard Qubes audio in the stubdomain, and telling qemu to emulate audio hardware that Windows is known to support.

Yes, it should work this way. A little concern is memory usage in stubdomain if you add pulseaudio there. Probably needs some smart tweaking ./configure of pulseaudio.

Or integrating frontend part into qemu directly (like we do with gui-agent). More work, but also more effective resources usage.

[marmarek]

This actually (either method) looks like a very good task for someone to contribute.

[Yethal]

There exists a project on github that provides pretty much exactly what Qubes needs out of the box.
https://github.com/duncanthrax/scream

also this https://www.audinate.com/products/software/dante-virtual-soundcard

[ElliotKillick]

Additionally, the RDP method:

1. Install FreeRDP on a Linux machine
2. Connect Windows and Linux via NetVMs or vchan
3. Enable RDP in Windows and connect to it from the FreeRDP client
4. The FreeRDP client supports sound and so it can be received over the RDP connection

[easydozen]

Yes, it should work this way. A little concern is memory usage in stubdomain if you add pulseaudio there. Probably needs some smart tweaking ./configure of pulseaudio.

The idea was realized here.
Beware, it's a highly experimental configuration.

The minimal pulseaudio was built using configuration tools, without deep-diving into the code: basic libraries, pulseaudio binary and two essential modules (vchan-sink and native-protocol-unix) the overall size is about 2MB.

Besides that, configuration of qemu have certain difficulties.
Before version 4.2 it was enough to tweak QEMU_AUDIO_TIMER_PERIOD to get good results in windows and linux VMs for intel-hda emulated sound card.
Nowadays we've got several improvements in qemu' audio subsystem. It seems that in qemu-4.2 the best out of the box result for linux VM could be achieved with es1370 - no need to fine-tune, acceptable sound quality, but there is no windows drivers for this sound card.

At the moment the Intel-hda audio device is used by default. It requires decreased latency on the
host side to get rid of a choppy sound:

• run pacat-simple-vchan with option -l (low latency);
• run pulseaudio with modified daemon.conf - (default-fragments = 3 and default-fragment-size-msec = 5 should be enough).

If anyone has thoughts how to make this work upstreamable, please let me know.

[marmarek]

I assume audio card model can be made controlled from libvirt config, right? In that case, it can be made configurable depending on needs (works out of the box, or better sound quality).
How extra pulseaudio and changed qemu config influence memory usage within stubdomain? Do you need to increase that?

Generally, I think stubdomain part should be upstreamable mostly as is. Just few improvements to be more configurable:

• make audio card model configurable through libvirt (I assume it's just removing options from stubdomain's init and adding appropriate xml part to libvirt template)
• start pulseaudio daemon only if libvirt requested audio device

As for the dom0 part, it's slightly less obvious. For example I don't know how best ship daemon.conf modifications. Also, currently pacat-simple-vchan is started for the target vm only - we'd need an option to do that for stubdomain instead (or in addition?). I is done here. Maybe control it with a feature (similar to forcing stubdomain gui)? Or a VM property to choose audio mode (pulseaudio in vm, pulseaudio in stubdomain, both?)?