Host audio crackling with audio-disabled Linux guest

[o2j63z2i0z9q]

During normal usage of my guest VM, I hear frequent pops in my _host_ audio, regardless of source (streaming music, playing local file, browser audio). It is correlated with graphical changes in the guest: the easiest way to trigger it is to scroll a window in the guest, and when the guest is not visible on screen, it never (as far as I can tell) occurs. This leads me to wonder if it is somehow related to the graphics driver. Guest audio is disabled in VM settings.

I don't recall this happening forever; it may have started with my last VirtualBox upgrade 2-3 months ago, but I don't remember exactly when or which version I upgraded from.

Has anyone experienced something like this before with a Windows host? I was unable to find anything by searching, though admittedly it's hard to find any host-audio-related threads/tickets in the sea of guest audio issues.

Host:

• Windows 10 Pro, Version 1909, Build 18363.1256
• Ryzen 7 3700X 8-core (16 thread)
• 32 GB RAM
• VirtualBox 6.1.16 r140961 (Qt5.6.2)

Guest:

• Manjaro 20.2 (also happens with Ubuntu 20.04 with identical configuration)
• 8 CPUs
• 16 GB RAM
• 128 MB video memory / VMSVGA
• Audio disabled

[fth0]

Please try if providing only 4 vCPUs to the VM makes any difference.

[o2j63z2i0z9q]

Just tried it, the problem still occurs with the same frequency using 4 CPUs with both Manjaro and Ubuntu.

[o2j63z2i0z9q]

I remembered that I also switched from using USB headphones (which would have their own DAC) to analog headphones last summer, so it's possible that was when it started and upgrading VirtualBox was not the cause.

[fth0]

If you can hear the pops without the headphones: What happens, if you remove the headphones (and other optional audio components), reboot the host (just in case), and perform your test?

Additionally, please provide a (zipped) VBox.log file from a VM run where the problem occurred.

[o2j63z2i0z9q]

This is a desktop system without built-in speakers, but I do have it connected to a TV via HDMI and can confirm that the problem happens identically with the audio that comes out the TV.

(I've rebooted many times since the problem started happening a few months ago, so I'm confident it's not transient)

Interestingly, I tried using Audacity to record the Windows WASAPI loopback device for my headphones while inducing the popping, and while I was able to hear the pops during recording, they were not present in the recorded audio played back after the fact.

Unfortunately I'm not versed enough in audio stacks to draw a conclusion from that.

I've attached the VBox.log from a clean boot of the VM that I then induced the issue with before shutting it down.

[fth0]

You seem to have two different versions of the VirtualBox Guest Additions (GA) installed: 6.0.0 and 6.1.16. Uninstall both, reboot the guest OS, and re-install the GA 6.1.16. If the problem persists, switch from full-screen to normal windowed mode and try again. Provide a new (zipped) VBox.log file for review.

[o2j63z2i0z9q]

I removed the guest additions, but saw that the vboxguest module was still loaded after rebooting. Looking further, it seems that this module is included in the upstream Linux 5.10 kernel, and indeed reports version 6.0.0: https://git.kernel.org/pub/scm/linux/ke ... =v5.10#n16

It feels like this must be expected, or else wouldn't everyone who runs a standard kernel have a problem?

Before reinstalling the guest additions package, I did add blacklist vboxguest to /etc/modprobe.d/blacklist.conf and rebooted, confirmed that the module was not loaded with $ lsmod | grep vbox, and was still able to reproduce the issue.

The problem occurs regardless of full-screen/normal windowed mode.

After reinstalling the guest additions package, I rebooted again, reproduced the problem, and shut down the VM, producing the attached log.

[Martin]

Can you test with the guest set to less than 8 vCPU?

[o2j63z2i0z9q]

I did so previously, but tried again now with the reinstalled guest additions.

Using 1 vCPU the problem still occurs (VBox.log attached).

[fth0]

00:00:28.924358 VMMDev: Guest Log: vboxguest: host-version: 6.1.16r140961 0x8000000f
00:00:28.929238 VMMDev: Guest Additions information report: Version 6.0.0 r127566 '6.0.0'
[...]
00:00:32.800069 VMMDev: Guest Log: 12:39:05.143410 main     VBoxService 6.1.16 r140961 (verbosity: 0) linux.amd64 (Nov 10 2020 10:11:31) release log
[...]
00:01:13.195845 VMSVGA: PIXEL shader: Failed to create:

Here you can see a few selected lines from your latest VBox.log file. The second line is generated by an installed GA 6.0.0. Many Linux distributions automatically install their own GA packages, and you should uninstall them before installing the original GA from Oracle.

It feels like this must be expected, or else wouldn't everyone who runs a standard kernel have a problem?

For comparison, I'm using Linux Mint 20 in my Linux guests, and I don't have your problems. The GA consist of several modules, and the vboxguest.ko module is built right when installing the GA, so it automatically has the correct version. You should uninstall any VirtualBox-related Manjaro package. I cannot tell if this solves your original problem, though.

[o2j63z2i0z9q]

As mentioned above, I tried uninstalling all GA packages and I still saw the "Version 6.0.0" line in the log until I explicitly blacklisted the vboxguest module that ships with the kernel. Perhaps additional work is required under Manjaro to ensure the vboxguest module from the GA package is loaded rather than the kernel built-in, but I haven't actually tried installing GA directly from Oracle's distribution yet, since I have suspected that GA isn't actually related to this problem (as it happens on other VMs too, where I previously didn't have the issue and was using Oracle GA).

That said, I'm starting to suspect this is a more general problem with my system and VirtualBox just happens to exacerbate it to the point where I notice it. I ran LatencyMon, and saw that even when no VMs are running, it detects unacceptable interrupt latency. I will investigate a bit there and report back if I find a solution.