Sound lost after a couple of changes of host audio output device

[boxer01]

I have found another bug, which looks similar to an old one from #17225: if I change the host output from speaker to the Bluetooth headphones, the sound of VBox goes to the headphones. Then I change back and the VBox sounds also goes to the speakers. But the next time I repeat the change to Bluetooth, the VBox ignores it. The sound form the host and programs, running on the host played in the Bluetooth headphones, but the sound from VBox is lost. If I turn the BT headphones off, the VBox sound returns to the speakers, but I can't get the VBox sound to the Bluetooth anymore. The only way is to save and restore the VM state or to turn the VM off and then on (restart).

All information about how I test the sound in VBox is in other ticket. I'm on 6.1.23 version 145326 now.

[boxer01]

Logs without audio debug from the previous day,6.1.23 version 145326

[boxer01]

Current logs with audio debug, 6.1.23 version 145326

[boxer01]

Debug sounds before and after the save state. Same in the new logs.

​sound before

​sound after

[boxer01]

This is followup for #20273.

[boxer01]

Still here as of 6.1.24, 6.1.25, 6.1.26, 6.1.27 rev. 146035.

[Pier Paolo]

Same problem, host: windows 10 virtualbox version 6.1.26 r145957 ubuntu guest with guest extensions 6.1.26 I have a wireless headphones, when I turn them off windows changes the primary output device to external speakers, virtualbox sound go out from the speakers. If I turn on again the headphones windows use them again as primary output device, the sound every other program goes out from the headphones, but virtualbox sound is not audible (in the headphones or from the speakers). If I turn off the headphones again, the sound is again audible through the speakers. Virtualbox vm become again able to make sound go out from the headphones only if I restart the vm.

[allenb]

I'm seeing the same (v6.1.26 on Win 10 host, Ubuntu 20.04 guest with extensions). I start the VM and get audio out my speakers. I then power on my bluetooth headset (paired with the host, not the guest) and get audio through the headset. Now, I power off the headset and lose all audio output. The first device switchover worked transparently, but the second does not.

My logs and the other logs posted above have this bit in common that appears when the current audio device is removed:

03:39:59.262856 Audio: Device configuration of driver 'WasAPI' has changed
03:39:59.266898 WasAPI: Failed to get default input device (OnDefaultDeviceChange): ERROR_NOT_FOUND 0x80070490
03:39:59.266961 Audio: Device configuration of driver 'WasAPI' has changed
03:39:59.611150 Audio: Found 3 devices for driver 'WasAPI'
03:39:59.611209 Audio: Device 'Speakers (Realtek High Definition Audio)':
03:39:59.611210 Audio:   ID              = {0.0.0.00000000}.{adeae8a7-b2b2-4b5a-bfc0-7e2e34875ede}
03:39:59.611210 Audio:   Usage           = output
03:39:59.611211 Audio:   Flags           = DEFAULT_OUT
03:39:59.611212 Audio:   Input channels  = 0
03:39:59.611213 Audio:   Output channels = 2
03:39:59.611224 Audio: Device 'Realtek Digital Output (Realtek High Definition Audio)':
03:39:59.611225 Audio:   ID              = {0.0.0.00000000}.{2230f5f5-c368-4cb0-8712-dcfb5d3248a7}
03:39:59.611226 Audio:   Usage           = output
03:39:59.611226 Audio:   Flags           = NONE
03:39:59.611227 Audio:   Input channels  = 0
03:39:59.611228 Audio:   Output channels = 2
03:39:59.611240 Audio: Device 'Speakers (Realtek High Definition Audio)':
03:39:59.611241 Audio:   ID              = {0.0.0.00000000}.{adeae8a7-b2b2-4b5a-bfc0-7e2e34875ede}
03:39:59.611242 Audio:   Usage           = output
03:39:59.611242 Audio:   Flags           = NONE
03:39:59.611242 Audio:   Input channels  = 0
03:39:59.611243 Audio:   Output channels = 2
04:52:38.518910 WasAPI: GetCurrentPadding([WasAPI] Output:0) failed during playback: AUDCLNT_E_DEVICE_INVALIDATED (@0x0)
04:52:38.524375 WasAPI: GetCurrentPadding failed on '[WasAPI] Output:0': AUDCLNT_E_DEVICE_INVALIDATED
 [[[ last 2 lines repeat 64 times ]]]
04:52:40.158486 AssertLogRel F:\tinderbox\win-6.1\src\VBox\Devices\Audio\DrvAudio.cpp(3351) unsigned int __cdecl drvAudioStreamGetWritable(struct PDMIAUDIOCONNECTOR *,struct PDMAUDIOSTREAM *): cbWritable
 [[[ last line gets spammed every ms or so ]]]
04:52:44.076609 32768 messages from group DRV_AUDIO (#91), muting it.

After that point, I got no guest audio output on any device. Audio played from within the host OS functioned normally. Disabling audio output and re-enabling from the mini-toolbar didn't change anything, neither does re-connecting the headset or changing the default audio output device in the host. Adding or removing a device no longer generates "Device configuration of driver 'WasAPI' has changed" log messages at this point.

It looks like the audio subsystem is trying to use the output device after it is removed and the device is invalidated. Inside the function `drvHostAudioWasHA_StreamPlay()`​, the code that generates the log message​ looks like this:

else
{
    LogRelMax(64, ("WasAPI: GetCurrentPadding(%s) failed during playback: %Rhrc (@%#RX64)\n",
    pStreamWas->Cfg.szName, hrc, pStreamWas->offInternal));
    /** @todo reinit on AUDCLNT_E_DEVICEINVALIDATED? */
    rc = VERR_AUDIO_STREAM_NOT_READY;
    break;
}

Implementing that "todo" may solve this issue.

[boxer01]

Replying to allenb:

It looks like the audio subsystem is trying to use the output device after it is removed and the device is invalidated. Inside the function `drvHostAudioWasHA_StreamPlay()`​, the code that generates the log message​ looks like this:

else
{
    LogRelMax(64, ("WasAPI: GetCurrentPadding(%s) failed during playback: %Rhrc (@%#RX64)\n",
    pStreamWas->Cfg.szName, hrc, pStreamWas->offInternal));
    /** @todo reinit on AUDCLNT_E_DEVICEINVALIDATED? */
    rc = VERR_AUDIO_STREAM_NOT_READY;
    break;
}

Implementing that "todo" may solve this issue.

Hi allenb!

Thank you (very much) for this deep analysis. I opened a duplicate ticket for this issue (#20630), because this is still an issue in the current 6.1.28 and .29 build. Socratis wouldn't like this (me opening the duplicate), but I have kind of no other way to point on this problem, and he is not around for a long time (R.I.P.)

As I probably already wrote in some other sound tickets, the trouble here is a sound backend refactoring in the last 5 years. It started with version 5.1 back in 2016, they tried to separate the sound from the main thread to the thread of its own. But this attempt was so botched, that they have to scrap it altogether and return to the 5.0 version of the sound system.

But a year later the attempt was repeated, and now they nearly succeeded. It also has some error, like timing problems and some other small things, but they were corrected in September 2018 with the version 5.1.22. I still use it as a productive one.

After the rest of issues were ignored over 2 years, somebody started yet another rewrite this (2021) February - March. It almost succeeded also, major errors were corrected back then, but we still see small issues like this one. The big trouble here: if you take a look at the SVN for the last 6 month (since April), you'll find out that 95% of audio change sets are about Validation Kit. I wouldn't like to tell, that proper testing and proper testing platform isn't important (I'm developer myself), but it looks like that developers here have no time to resolve some bugs from current running audio system, spending nearly all the time for testing platform development.

Let us hope, that this will be addressed soon.

[PavloUnn]

(duplicating here in addition to #20630): @boxer01, it looks like the issue is not bound specifically to Bluetooth devices. It's for any detachable device. I've opened #20723, just in case.

[boxer01]

Replying to PavloUnn:

(duplicating here in addition to #20630):

Thank you for finding my other tickets about this issue. As you correctly assumes, this is not about BT, this is about another device. So this issue wouldn't be triggered if I switch from the built-in speakers to the headphones on the built-in jack, because this is the same device. Only switches to another device would provoke this.

With the current version, I know the only working workaround - to save the VM and to start it again. One can also shut down and start the VM. No other tricks are working right now. And you already found the comment in the other ticket, which shows the part of the source code, which probably causes all of this. We just have no time, knowledge and other possibilities to correct it.

You may also take a look on my other sound-related tickets, which are still open. And the tickets I mentioned in my comments. A small overview: the sound troubles started about 5 years ago. We now in the third version (rewrite) or wave of it. Some old bugs were fixed, but the new arrived. So the last rewrite was done in March 2021, and so this issue is already slightly over one-year-old. As you may see from other tickets from other waves, it takes time to fix it. Sound isn't probably on the top of the list, and scenarios like this has even lower priority. All we can do is hope and pray.

[lukaszo]

My version is 7.0.8 R156879, the problem still occurs. However, I found a slightly more convenient circumventing of the problem. You don't have to start the machine again.

Windows+R -> ms-settings:sound -> advanced sound options

Now I'm trying to change the type of VB output to another. It doesn't always work or I haven't found a relationship yet.

[boxer01]

Replying to lukaszo:

Windows+R -> ms-settings:sound -> advanced sound options

Now I'm trying to change the type of VB output to another. It doesn't always work or I haven't found a relationship yet.

Thank you for your remarks here. I tried this and it only works once. I can change the output device in the advanced sound settings of the new Windows settings app. But the next time I switch the devices back to the speakers and then once again to the other device (BT Headphones in my case), even this workaround doesn't work. And in the end it is still a workaround. So I have now one more chance before I have to save the VM state or restart it.

The cause of the problem is described in this ticket about 2 years ago, but still not fixed. Looks like Windows have some original values every time we connect the program to another audio device. So reusing the values from the last connection time doesn't work. Or something like this. ;-)

Would be nice if somebody finally correct this.

Another interesting question:is it possible to somehow do this switch automatically? So one wouldn't need to open some windows and operate with the mouse, but just start some PowerShell script?

[lukaszo]

I spent some time trying to find a command, script (e.g. using windows powershell or external application). It is possible to change the output, but not for a specific application. To speed up the manual workaround process, I have another shortcut: ms-settings:apps-volume. The relationship that works for me in 90% is switching between specific devices, and I have 4 types of them:

• Default
• Headset (Plantronics) (it has USB dongle)
• Headphones (Bose) (it has USB dongle, too)
• Speakers (Realtek HD Audio)

When the problem occurs, I switch to the Headset (exactly this and only this). Then I hear the sound in my little earpiece (also BT). Then I go back to Default or Headphones again. I do everything on the Oracle VM VirutalBox application/process.

[boxer01]

It looks like the audio subsystem is trying to use the output device after it is removed and the device is invalidated. Inside the function `drvHostAudioWasHA_StreamPlay()`​, the code that generates the log message​ looks like this:

else
{
    LogRelMax(64, ("WasAPI: GetCurrentPadding(%s) failed during playback: %Rhrc (@%#RX64)\n",
    pStreamWas->Cfg.szName, hrc, pStreamWas->offInternal));
    /** @todo reinit on AUDCLNT_E_DEVICEINVALIDATED? */
    rc = VERR_AUDIO_STREAM_NOT_READY;
    break;
}

I've looked for some kind of side solution for this situation and came across the official WASAPI ​ documentation. This situation, where the endpoint becomes somehow invalid (AUDCLNT_E_DEVICE_INVALIDATED) and the resources of the session or some streams in it have to be released and reallocated again, is explicitly described in the linked ​document. One only need to do this. ;-)

[boxer01]

Replying to lukaszo:

I spent some time trying to find a command, script (e.g. using windows powershell or external application). It is possible to change the output, but not for a specific application.

I'm looking right now for the ways to reset the WASAPI stream or session. What I have ​ found is the way to reset the complete Windows sound system. I wrote a small .cmd file, so it could be started as administrator and automatically turn the sound system off and on again. ;-)

net stop audiosrv /y
net stop AudioEndpointBuilder
net start audiosrv

One have to see, which other services are hanging on the audio service and turn them also on afterward. In my case, it is Lenovo Hotkey service. And I use the "/y" switch to avoid all the questions.

There are other suggestion to disable and enable the "problematic" device, but this doesn't help me much. And the above-mentioned method also helps only once. Afterward, on the next switch, one still have to save state of VM or restart it completely.

Fun fact - I finally achieve the state, where my alternative (BT) sound device was reached by VBox, but the primary one (speakers) wasn't. Just the mirror situation to the usual situation in this bug. ;-)

What we need here is some kind of software, which could get any WASAPI session or stream(s) in the session and reset it (streams or session). The thing which should be done in this situation by VBox itself. But this bug and the place for the fix is well documented for over 2 years, see above.

[lokimon]

Just chiming in. Windows Host. Ubuntu Guest.

I'm seeing the exact same thing. Bluetooth only sometimes gives out on audio through VirtualBox. Internal speakers continue to work.

Same log signature as well.

Running the above 3 commands as administrator from Windows from boxer01 did get audio back working again without having to keep rebooting the guest.

But it only worked the first time here as well.

[pentagonik]

Thank you all for the analysis and the detailed reports. This issue has not been forgotten. I'll have a look at this as soon as time permits.

[pentagonik]

I think I managed to reproduce and fix the issue here. Will provide a 7.0 test build shortly for you to try out.

[pentagonik]

Uploaded a new Windows test build 158794 which should contain a fix here [1].

Please let me know if this fixes the issue for you.

[1] https://www.virtualbox.org/download/testcase/VirtualBox-7.0.11-158794-Win.exe

[lokimon]

Just letting you know.. I have started testing. I can report back in a couple of days.

[boxer01]

Replying to pentagonik:

Uploaded a new Windows test build 158794 which should contain a fix here [1].

First, the good news. I've tested exactly this situation, and this issue is gone. I can change the device (from BT to speaker and back) as many times as I like, and I still can hear the sound. Thank you very very very very much! ;-)

I have to make a longer test run and see it in daily usage, so I wouldn't see any other troubles. But at first sight, this thing looks good.

As it was already in previous cases, I think I found a new troubling thing. ;-( I quickly tested this yesterday evening before going to sleep. As I woke up the computer this morning, there was no sound from VM, even if it was on the primary sound device (built-in speakers). Saving the state and restoring it helped, as usual. I tried to provoke this by manually hibernating this Windows computer, but after waking it up, everything was okay. I put some logs here; I don't know if it would help any further. I would observe it further.

A couple other questions besides: could these old tickets #17614, #17738, #18695, #20273 be closed? I think that this issue is gone.

Other question: I have another audio ticket #21100, this time about input (microphone). It has been unanswered for nearly one year. What could be done to put this issue somehow forward?

[boxer01]

New logs after hibernating

[lokimon]

Working great so far! Thanks!

[boxer01]

Still here in 6.1.47-158777. Are there any chances for the back port into the 6.1 branch?

Otherwise, everything runs fine in the 7.0 test version. No problems with hibernation since then, hopefully it was a one time thing.

[pentagonik]

The 6.1 branch does not contain the fix yet, but the fix will definitely go into the next 6.1 maintenance release then.

[riverskyfang]

Where can I download this patch currently, I want to fix my own build.Thanks!

[pentagonik]

Patch for 7.0

[pentagonik]

@riverskyfang I just attached the patch so that you also can have a go on this. Please let me know if this fixes the problem for you.

[riverskyfang]

Replying to pentagonik:

@riverskyfang I just attached the patch so that you also can have a go on this. Please let me know if this fixes the problem for you.

This patch works fine for me! Thanks!

[pentagonik]

Great to hear that, thanks for verifying.

[lokimon]

Just to verify.. This change is in mainline version 7. So if I get a upgrade notification, it will still be fixed? Just wondering if I need to stay on this test build or can update.

I really appreciate the fix. Using VirtualBox is so much less frustrating. :)

[pentagonik]

Correct -- as soon as there will be a new 7.0 maintenance release, that fix will be built-in.

[boxer01]

Also solved for 6.1 as of 6.1.47-159049. This one could be closed.

[galitsyn]

Hi guys,

We just released a new version of VirtualBox today. This issue should be fixed there. Closing it. Please leave a comment if it is still actual for you. As usual, builds are available on Downloads page. Thank you for reporting.