virtualbox.org

Hello,

I am running a Windows XP guest on a Windows 10 1909 Pro host with VirtualBox 6.1.4. In the VM's configuration, I have activated audio and audio output, but deactivated audio input. When I start the guest, it still grabs the host's microphone, indicated by a microphone icon in the host's task bar info area. Only if I activate and then again deactivate audio input in the bottom control area of the VM's windows, the VM seems to stop using the microphone and its icon disappears.

How can I prevent the VM from grabbing the microphone alltogehter?

Thanks, mjf

I was having the same problem with a lubunutu guest on windows 10 host.

On my system, it also caused a slow leak of continuous ~1% host audio device processor utilization, and it prevented my laptop from sleeping when I close the lid because an audio stream was constantly active.

Changing the Audio Controller to "Intel HD Audio" in the VBox audio settings seems to have fixed it in my case.

I noticed the same bug recently, but only after enabling Audio In ONCE. Prior to that, the VM (which predates the audio-in support) correctly never used the microphone.

The relevant line in the XML file is: and I'd bet that prior to that first use the last element was just completely absent. (I'll try it next time I'm in a position to restart the VM and check). So the bug is likely a failure to parse that correctly, and treat the existence of the "enabledIn" element as just "that means on" rather than actually processing the key properly, doubtless as a change in format at some point in time.

It's a surprisingly impactful (yet trivial) bug to never have been fixed, but obviously none of the Paying Customers have noticed it yet. I expect that like me they've probably never enabled it even once, which is what's required to trigger it.

arQon wrote:doubtless as a change in format at some point in time

You surely hit the nail on the head. Here's an example from two VMs with the same audio settings:

.vbox file wrote:

<VirtualBox xmlns="http://www.virtualbox.org/" version="1.16-macosx">
        <AudioAdapter codec="AD1980" driver="CoreAudio" enabled="true" enabledIn="false"/>

.vbox file wrote:

<VirtualBox xmlns="http://www.virtualbox.org/" version="1.17-macosx">
        <AudioAdapter codec="AD1980" driver="CoreAudio" enabled="true" enabledOut="true"/>

When experimenting, note that newer VirtualBox versions still use quite old formats of the .vbox files if possible. Only when you configure a newer feature, the .vbox file is converted to a format new enough to support that feature. For example:

Create a new VM Test with VirtualBox 6.1.12, copy the Test.vbox file, Enable Nested VT-x/AMD-V, and compare the Test.vbox file to the copy you made earlier.

Oh, definitely - I ran across something similar several years ago where a clone of a VM and the original it was cloned from had RADICALLY different performance, which I eventually tracked down to IOAPIC=2 or somesuch. Ever since then, I create a new VM every time I update VBox and diff the XML, and every year or so it turns up something useful.

I haven't had a chance to tinker with the VMs since my last post, but I remembered there's a workaround for the bug by enabling AudioIn via the host/guest menuu on a live VM, then disabling it again. That gets the AudioIn to behave corrrectly, as evidenced by the host's mic icon disappearing, making it possible to test various XML tweaks on a different VM and see what happens.

Unfortunately, I didn't have any luck guessing what the "old" working XML was (neither the delta you noted nor my original guess actually fixed VBox incorrectly accessing the mic) so I'll have to dig that out from a backup at some point, just to satisfy curiosity. I can confirm that the bug appears to only be in the AC97 parser though, and that as Mesosphere says it works correctly with HDA.
edit> No, the bug is there with HDA as well.

After some additional tests, I think the problem is also independent of the settings version.

Note that the default value (i.e. if the attribute isn't present) has changed with the config file settings version. Until 5.1.x (settings version 1.16) there was no separate configuration of audio input. With 5.2 the explicit enabling of audio output and input was added (but for a reason which I don't understand we did not introduce a new settings version, this change came shortly before 5.2.0 was released), and therefore the default with settings version 1.16 was that if it isn't mentioned, it's enabled. Additionally, starting with 5.2 only attributes with non-default value were written to the config file, which reduces the time spent on reading and writing the XML config. With VirtualBox 6.0 (settings version 1.17) the default changed to disabled.

This "now you see it now you don't" behavior can be a little non-obvious, but it will only go truly wrong if one creates a VM with a new VirtualBox version and runs it on 5.1 (which will work, because old VirtualBox versions will read what they understand of the newer VM config), because that doesn't know about this detail and loses it, implicitly enabling both audio output and input when the VM config is later used by VirtualBox 5.2 or later.

Thank you @klaus for the detailed explanation, very much appreciated.

But the behavior mentioned in the topic title also occurs without using an older VirtualBox version, and the conversion of the settings doesn't play an important role then IMHO. Please (let somebody ) try the following easy test:

Take a Windows 10 2004|20H2 host with VirtualBox 6.1.16 installed. Create a new VM for an Ubuntu (64-bit) guest, add for example a Linux Mint 20 ISO image to it and modify the configuration so that it gets converted to settings version 1.17 or 1.18 (*). Start the VM and the Linux Mint live system. The status bar of the VM window will match the audio settings and show the audio input as disabled, but the Windows 10 status bar will show the microphone as enabled. Enabling and disabling audio input from the VM window status bar will really disable the audio input in this case.

(*) In my own tests, I've enforced the conversion by enabling Nested VT-x/AMD-V (-> 1.17) or by adding a virtio-scsi storage controller (-> 1.18). In the past, I've sometimes noticed that a conversion had taken place without me having deliberately changed the VM configuration. Which events trigger a conversion of the settings besides manual configuration changes?

The conversion to a newer version is triggered by using the features of a new version. A short (but usually reasonably complete) summary of which settings were added when is in https://www.virtualbox.org/browser/vbox ... alBox.xidl - too bad that this file is so fat that it exceeds the limits of our source browsing tool. Download it and search for "SettingsVersion". If you want the latest settings version 1.18 then just add a virtio-scsi storage controller (bumps the settings version) and delete it again (does not downgrade the settings).

If you observe that the actual VM settings change without user intervention (and without involving VirtualBox 5.1 or older) please let me know - this applies to audio or other changes.

The actual usage of audio input when the VM should not have access is the topic of an ongoing investigation (yes, we can reproduce) and is unrelated to 'spontaneous' settings changes.