Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 703342 - >=app-emulation/virtualbox{,-bin}-6.0.2[-pulseaudio] no audio in VMs
Summary: >=app-emulation/virtualbox{,-bin}-6.0.2[-pulseaudio] no audio in VMs
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Lars Wendler (Polynomial-C)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-19 08:14 UTC by Francesco Lamonica
Modified: 2019-12-23 13:42 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Lamonica 2019-12-19 08:14:10 UTC
virtualbox 6.0.2 and over have changed the default buffer size for ALSA audio and that totally screwed up audio for guest VMs (either windows or linux)
(see upstream bug https://www.virtualbox.org/ticket/18342)

This behaviour does not seem to happen (discussed on IRC with Polynomial-C)
when pulseaudio is installed.

There was a patch provided (attached to that thread) to restore previous buffer but after a year it has not yet been merged.
Now virtualbox 6.1.0 has been released and the audio is still broken and the patch does not apply anymore, I modified it and added a comment to the upstream ticket. 
I think both patches should be added on gentoo ebuild to restore functionality at least on non-bin VBox; they are working on my system for all my VMs.

The patches basically restore pre-6.0.2 ALSA buffer size.
Comment 1 Lars Wendler (Polynomial-C) gentoo-dev 2019-12-23 13:42:14 UTC
I've asked upstream about the issue and why it didn't make any progress and that's what I got as reply (with kind permission to be quoted here):


16:26:26 <@klaus-vb> Polynomial-C: absolutely no idea why this patch helps the user at all. it has nothing to do with ALSA (that would be in DrvHostALSAAudio.cpp) it shouldn't be code which is truly active when VRDE and audio recording are not active (which should be the case in typical setups). even if it is active the buffering for those audio paths should not affect ALSA - of course it's one of those "should not" which may be totally wrong due to timing impact or implementation bugs.