Playing audio through Windows VM causes system wide audio corruptions/degradation

My audio works fine in all my Qubes (debian, fedora, whonix) except windows and once run a Windows VM and play audio through it the quality is extremely poor (cracking, scratchly, very poor quality) and then after that playing the same audio (e.g. youtube video) through any other VM is also corrupted and sounds really bad identical to the windows vm. I am using the integrated speakers of my lenovo laptop not external.

You must reboot the PC and then audio through all the non-windows qubes is again normal. But audio quality through windows VM remains the same and attempting playing audio through it will corrupt audio instantly in all other VMs so it is sounding exactly the same until reboot.

As for the windows VM my issue sounds identical to what user @Isolator reported here except my case causes audio in all other VMs to then significantly degrade to match the audio quality in the windows VM. Regarding the Windows VM, I have followed all the troubleshooting steps mentioned in that post and also pasted below (collapsed).

I am on a fresh Q4.1 install running dom0 kernel-latest i think 6.0.2.2. Everything is working fine except this. Windows 10 VM is setup as per qubes community documentation and installed latest QWT with default parameters. The audio quality issue occurs with and without QWT installed.

And as mentioned I have ran through all the windows specific troubleshooting steps here:

Windows Specific Troubleshooting Steps I Attempted

I’ve tried changing audio models and this is what I got so far:
ac97 - doesn’t work (I guess no driver? as it was unrecognized in windows device manager)
es1370 - doesn’t work.
ich9 - works, but has loud constant crackling.
ich6 - works best, but still occasional frequent crackling.

I tested ich6 further and this is what I got:
crackling frequency seems to be dependent on the load, ie it increases when I move application window around, or open some other application like task manager.

Initially windows vm had 4Gb of memory and 2 cores, then I increased it to 8Gb and 4 core and further to 12 Gb and 6 cores
there seems to be no major difference between 4/2 and 8/4 configuration, but curiously enough sound quality seems to get worse with 12/6 configuration.
My system has 34 Gb of memory and a 6 core CPU, and I had no other vms running except for networking service qubes.

Also I’ve tried these commands, without any noticeable difference:
qvm-features timer-period 1000
qvm-features out.latency 10000
qvm-features out.buffer-length 4000

Sound output is also emulated output (if that’s what it’s called), as I don’t use any usb adapters and the like.worse with 12/6 configuration.
My system has 34 Gb of memory and a 6 core CPU, and I had no other vms running except for networking service qubes.

Also I’ve tried these commands, without any noticeable difference:
qvm-features timer-period 1000
qvm-features out.latency 10000
qvm-features out.buffer-length 4000

Any help troubleshooting would be very much appreciated…

:grinning: :pray: :pray:

1 Like

You should try using sys-audio. Restarting it instead of Qubes should at least makes it less cumbersome. In my case, Win7, sys-audio actually helped to get a lot better, clear sound.

I think this is mostly due to a) the pipeline from VMs through pulseaudio/pipewire allowing config changes to dom0 hardware based on source material sample rate/width changes (even from VMs) plus b) recent kernel/sound driver work creating defects that can be triggered by these types of hardware/driver changes.

I’ve found that playing any audio file in dom0 at (software) volume 0 in an infinite loop prevent the dom0 kernel/driver bug from triggering and allows audio to work, probably as this forces software blending of sources instead of hardware/driver config changes to match a single source. Of course this annoyingly uses processing power to block a defect trigger.

Apparently the kernel/driver bug doesn’t seem to trigger in bare metal Linux but only in Xen hosted Linux. It appears to be related to dma buffer creation/handling.

B

2 Likes

Problems are only with the pipeline from windows VMs, linux pipeline works fine. Sounds more like defect in the implementation of a Xen/Qubes audio backend for windows VMs specifically, seeing as it’s a new feature.

Is there already a bug report?