Sound totally broken for Windows XP guest under Linux host

[dinosaur0]

I just updated to VirtualBox v6.0.2 and noticed immediately that audio got totally, utterly broken and non-functional (even going up to crash programs using sounds) for my Windows XP guest under my Linux host.

Sound was working beautifully with v6.0.0 (*) and I reverted to it...

Note that the version of the extpack (6.0.0 or 6.0.2) installed (both in VirtualBox and in the guest OS) does not seem to matter: it's broken at VirtualBox level itself, apparently.

This is a showstopper bug: pretty please, fix it quickly !

Attaching relevant logs to this ticket.

---

(*) after bad sound lag issues in the late v5.2 releases, akin to what I encountered with even older releases and reported in this ticket: https://www.virtualbox.org/ticket/15924 )

[dinosaur0]

Sound still totally non-functional/broken in VirtualBox v6.0.4...

I'm back-pedaling again and reinstalled v6.0.0.

[Willie]

Same problem, happens on host systems without Pulseaudio. Tried with Linux, Windows 8 and Windows 10 guests.

[Willie]

Bug also occurs on 5.2.28

[Willie]

The attached patch changes the buffer size to 100ms, which was the default in older VBox versions and this fixes the broken sound.

[dinosaur0]

This bug still plagues v6.0.8 and I can confirm that Willie's patch does solve the issue (I finally managed to get around building VirtualBox for my distro).

[AlienPenguin]

I can confirm too that patch restores audio on windows (7/10) and ubuntus (1604, 1804, 1904) on a gentoo host (not running pulseaudio).

My Window guest is using intel HD audio while ubuntus are on ich97; they all report their sound card working fine. Gentoo sound works fine too.

As reported (on IRC) by gentoo package maintainer, if pulseaudio backend is installed then there's no audio problem even without the patch.

The problem does not occur on binary 5.2.20 while it does (no audio) on 5.2.30 as reported by Willie (above) seems to occur in 5.2.28 as well (I did not try though)

[Socratis]

Can you try the following "runtime patch"?

VBoxManage setextradata global VBoxInternal2/Audio/CoreAudio/BufferSizeMs="100"

You can get rid of it with:

VBoxManage setextradata global VBoxInternal2/Audio/CoreAudio/BufferSizeMs

[shillshocked]

I tried the "runtime patch" both before I ran the vm, and afterwards to no effect. Is there some otherwise special timing to invoke this?

How do you apply the patch to virtualbox-bin?

[dinosaur0]

I can confirm that the VBoxManage command does not work with the original/unpatched VirtualBox v6.0.8. Sound still broken.

[Socratis]

To tell you the truth, I wasn't expecting the "patch"/preferences to work, otherwise the developer that deals with the audio parts would have mentioned it. I simply thought it was worth a shot, sorry for the noise everyone...

[dinosaur0]

This bug is still present in VirtualBox v6.0.10...

Applying Willie's trivial patch to the sources and recompiling them gives me functional sound again.

How much time will it take for you guys to integrate a one liner patch and restore ALSA compatibility ?... :-(

[pentagonik]

The "runtime patch" provided by Socratis in theory should work, but for Linux / ALSA the line to use should be:

VBoxManage setextradata global VBoxInternal2/Audio/ALSAAudio/BufferSizeMs "100"

As audio is *very* timing sensitive (as it's realtime stuff to process), we still hesitate to change any of the default values for now, unless we get a better overview that the 100ms indeed works better than the current default of 250ms.

[dinosaur0]

Replying to pentagonik:

The "runtime patch" provided by Socratis in theory should work, but for Linux / ALSA the line to use should be:

VBoxManage setextradata global VBoxInternal2/Audio/ALSAAudio/BufferSizeMs "100"

Yes, this runtime command allows to get a functional sound with the un-patched VirtualBox v6.0.10. If only it were documented (and a note in the change log added to explain how to revert a default value you changed in a new version)...

As audio is *very* timing sensitive (as it's realtime stuff to process), we still hesitate to change any of the default values for now,

Err... The default value used to be 100ms, until you screwed it up all by changing it in 6.0.2 !

This is a regression bug, and as such, the change that causes the regression shall be reverted until you comprehend how and why it screws up things, and what to change in your code to try the new value again later.

Plus, I do not see why you did that change in the first place, while audio worked beautifully with the old value before.

unless we get a better overview that the 100ms indeed works better than the current default of 250ms.

It works beautifully at 100ms, it is totally non-working at 250ms: what "better overview" do you want ???

At least, you could make it so that 100ms is used for the ALSA backend, or that a parameter (a spinner to adjust the value) is provided in the Vbox UI (sound tab), allowing to change that buffer length default, with proper explanation provided (tool tip in the UI, chapter in the doc).

[Socratis]

Replying to pentagonik:

The "runtime patch" provided by Socratis in theory should work, but for Linux / ALSA the line to use should be:

VBoxManage setextradata global VBoxInternal2/Audio/ALSAAudio/BufferSizeMs "100"

Duh! Of course! (smacks forehead)
The CoreAudio is used on OSX, not on Linux hosts. Should have thought about it...

[Willie]

The small patch should be merged into the main branch. AFAIK the buffer size changed by the patch is only used when using Alsa.

Any Windows/Mac system is unaffected and since most Linux distros use Pulseaudio these users should also be unaffected when applying this patch.

That leaves the (probably) small part of pure Alsa users who don't have any sound at all without this patch.

[dinosaur0]

Still not fixed in v6.0.12...

A 8 months regression bug, that can be fixed by simply changing one line in the code, and still no change after all this elapsed time and versions.

Are VirtualBox developers trying to beat the world record for the longest time taken to fix the simplest bug ? :-(

[dinosaur0]

And... Still not fixed in v6.0.14 ! >:-(

[Segfault]

Replying to dinosaur0:

Still not fixed in v6.0.12... Are VirtualBox developers trying to beat the world record for the longest time taken to fix the simplest bug ? :-(

Microsoft holds the record, 19 years. Takes some beating.

[rob_on_earth]

Had the same problem for almost a year and always thought it was just me. Even ended up building Alsa from source in the Guest to try and track down the issue.

The work around has worked for me, but I am worried by the lack of progress in creating a permanent resolution.

The change was made in 6.0.2 where 6.0.0 worked correctly and 5.2.28 where 5.2.26 worked correctly.

The most obvious option to most users affected, is to revert the change. I had a look at the source code and the change just to the DrvAudio.cpp file is non-trivial. No idea how many other changes in that release also rely on the changes around those changes, let alone the Buffer changing from 100ms to 250ms.

I cannot see any way of getting the changeset along with commit message from SVN in the way you would with git. The changelog does not list an obvious Bug number. A commit message or Bug number might give us more information why the change was made.

So, if the change has to stay because it fixes something else that can now no longer be broken, a likely fix would be to either detect the circumstances when 100ms is a better option (no idea where to start with that) or to have a GUI control in the VirtualBox manager that users can set e.g. Buffer size.

If that is not a viable option due to the impact of altering the GUI, then surely this is something that should be noted in the Documentation.

The only reason I can think this has not been resolved is lack of users reporting it. As I noted, I have had this issue for a long time and never once thought VirtualBox was to blame. But then maybe it is just me and the few others that encountered this.

Really would be great to know why the original change was made. Any idea how we can find out?

[Willie]

Replying to rob_on_earth:

Really would be great to know why the original change was made. Any idea how we can find out?

I compared a few different VirtualBox versions and it seems the buffer size was rewritten as part of a bigger project to fix multiple audio issues. It took me about a day of hacking the code before I found the culprit (because of the amount of changes). The change to the buffer size may have been accidental, it may have been introduced to streamline the code (i.e. to keep close to some optimal default values) or it simply didn't cause issues for the developer.

However, I do think the change is trivial. Because the fix only changes the buffer size on Linux systems that don't have Pulseaudio. Looking at these comments it seems plenty of pure Alsa users (maybe every pure Alsa user) are affected. Reverting the change, i.e. applying my small patch to the source code for future versions, seems to be the best solution.

[AlienPenguin]

Hi all, the problem persist with virtualbox 6.1.0 as well.

The patch provided for VBox 6.0.x does not apply anymore; i made some small changes and it is now working again on my Linux Host (Gentoo with alsa and no pulseaudio).

I attached it in case you might want to try it on your systems.

[AlienPenguin]

patch to restore audio on linux alsa hosts

[Klaus Espenlaub]

The proposed patch is a complete mystery. It changes the buffering of audio for VRDE and/or the audio part of the recording feature. This change is miles away from anything ALSA related it's not suitable for integration (all ALSA specific audio handling is in DrvHostALSAAudio.cpp).

I can't understand why it has any effect on ALSA. My vague guess is that the change somehow subtly affects timing in the audio code overall, but that can't be a fix, that's at best a really ugly workaround.

[AlienPenguin]

@klaus, I totally i agree that, stated your analisys, the patch is not a valid / suitable fix, on the other hand you have to reckon that sound has been totally broken on all guests for linux hosts that do not (won't or can't) rely on pulseaudio for the whole last 12 months and this regression deserves some priority boost. The hack, simply restores the status quo that was in place before VB 6.0.2 (and that was probably working by chance)

[Willie]

The patch is not really a mystery, it simply sets a default buffer size on an internal audio stream if no buffer size is set yet. The audio buffer size of 100ms is only used if Backend.cfBufferSize is not explicitly set. There are two reasons why this patch (probably) won't hurt other audio systems:

• Other audio drivers seem to explicitly set the cfBufferSize. This patch only sets a buffer size if nothing is set yet (i.e. it doesn't override anything).
• The default buffer size was 100ms in versions before 5.2.30. So this patch reverts a setting that always worked before.

As an alternative it may be possible to set the the cfBufferSize in DrvHostALSAAudio.cpp so the generic audio part can be left unchanged.

[Willie]

This problem is still present in version 6.1.12.

Maybe a virtual box developer can reproduce it? Should be simple, use any Linux environment without Pulseaudio.

[Willie]

The patch no longer works with version 6.1.20.

But great news, the patch is no longer needed! Alsa audio works fine again. If others can confirm this we can finally close this bug.

[jkr13]

Replying to Willie:

(...) the patch is no longer needed! Alsa audio works fine again. If others can confirm this we can finally close this bug.

I can confirm - I just struggled with the same issue today and upgrading to 6.1.30 fixed the problem completely.