FreeBSD FBSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #3 r340586: Sun Nov 18 14:13:13 EST 2018 root@FBSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1300003
virtualbox-ose-5.2.22 General-purpose full virtualizer for x86 hardware
virtualbox-ose-kmod-5.2.22 VirtualBox kernel module for FreeBSD
I had several virtual machines running on 12-current and all were working perfectly. Now on 13-current there seems to be issues with multimedia. Specifically videos do not play correctly.
Steps to repeat:
open Firefox 63.0.3 in a VM
go to youtube
try to play any video
Does it play successfully?
On the physical host I am able to successfully play any video with sound in Firefox.
I see a similar issue with virtualbox guests on FreeBSD 12 at the moment. As well as youtube videos not playing correctly for me I also don't have any audio. I'd like to listen to spotify using a virtual machine guest but can't at the moment. If anyone has any suggestions on what to try to fix this issue I'd be really appreciative. Thanks.
I too have this problem on FreeBSD 12.0-RELEASE-p2. Virtualbox-ose-5.2.22_2 installed from pkg does not play sound inside any guests. Driver OSS is selected for the guest and sound works normally on the host itself, but will not produce any sound from inside the guests.
I have similar problem too. I think that workaround to it is to install virtualbox from port and to use different sound server. Virtualbox-ose-5.2.26_1 with pulseaudio configuration works fine on my FreeBSD box (12.0-Release / amd64).
Created attachment 203632 [details]
Screenshot of YouTube with KDE, Manjaro Linux
Created attachment 203633 [details]
Screenshot of Vimeo with Lubuntu and with GhostBSD
Looking For Something on Vimeo
Comment on attachment 203632 [details]
Screenshot of YouTube with KDE, Manjaro Linux
First Image of a Black Hole! - YouTube
Playback ceases before the advertisement ends; the main video does not begin.
(In reply to Eijiro Shibusawa from comment #3)
> … I think that workaround to it is to install virtualbox
> from port and to use different sound server. … pulseaudio …
How might I do this with poudriere?
I experimented with a couple of lines in
but I guess that my lines were wrong, because the end result is still bugged by stalling after a moment's playback.
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sat 13 Apr 2019 11:23:39 BST
FreeBSD 13.0-CURRENT r346108 GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % poudriere jail -i -j head | grep -i version
Jail version: 13.0-CURRENT 1300018
Sorry, ignore my previous comment. I had forgotten to switch from OSS Audio Driver to PulseAudio in host driver preferences for the guest.
The end result _is_ good.
Here's my Makefile.local, two lines:
I am experiencing this too, so I found this page and turned on the audio debugging it mentions:
and in the logs, everything seems to be working, until it shows this:
00:00:18.694520 Audio: Stream '[OSSAudio] Output' could not be created in backend because of missing hardware / drivers
which seems to be from line 3110 of src/VBox/Devices/Audio/DrvAudio.cpp. This is because VERR_AUDIO_STREAM_COULD_NOT_CREATE is getting returned by ossStreamOpen in src/VBox/Devices/Audio/DrvHostOSSAudio.cpp, which sets rc = VERR_AUDIO_STREAM_COULD_NOT_CREATE at the top. This looks like a logic error. Setting rc = VINF_SUCCESS at the top of ossStreamOpen allows further progress.
But still there's no sound, it looks like we're hitting this assert:
AssertMsgReturn(pCfgAcq->Backend.cfPreBuf <= pCfgAcq->Backend.cfBufferSize,
("Acquired pre-buffering size must be smaller or as big as the buffer size\n"),
in src/VBox/Devices/Audio/DrvAudio.cpp. I think there's some sort of buffering issue which I don't fully understand. If you play around with the buffer sizes in s_OSSConf in src/VBox/Devices/Audio/DrvHostOSSAudio.cpp you can get sound, but it's choppy and stops working, reporting lots of buffering issues and eventually stops. And that's as far as I've gotten right now. Perhaps someone else can pick it up and find what's going on or perhaps I'll come back to it at another time. I'll post the patch for now.
Created attachment 205654 [details]
patch which fixes logic error in DrvHostOSSAudio.cpp/ossStreamOpen
Here's the logic error patch.
Created attachment 205683 [details]
VBox DrvHostOSSAudio.cpp changes since 5.2.16
I've just dug a bit for changes in VBox releases related to the src/VBox/Devices/Audio/DrvAudio.cpp, looks pretty interesting.
(In reply to Sergey A. Osokin from comment #11)
Hey, thanks. It seems like those were part of some major changes of the audio stuff. I wonder if we should consider reverting upstream revs r73370 r73529 r73689 r73695 r73696 r73838 and r76553 and see what happens.
(In reply to Steve Wills from comment #12)
in a case to revert those revisions the patch looks smaller.
Are there anybody can try it and report?
Thanks in advance.
Created attachment 205706 [details]
Reverting upstream revs r73370 r73529 r73689 r73695 r73696 r73838 and r76553
(In reply to Sergey A. Osokin from comment #14)
/tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.32/src/VBox/Devices/Audio/DrvHostOSSAudio.cpp:160:21: error: no member named 'cBits' in 'PDMAUDIOPCMPROPS'
pProps->cBits = 8;
In log file:
00:00:07.070098 OSS: Failed to open /dev/dsp: Operation not supported (45)
00:00:07.070110 Audio: Creating stream '[OSSAudio] Line-In' returned an invalid backend configuration, skipping
00:00:07.070127 OSS: Failed to open /dev/dsp: Operation not supported (45)
00:00:07.070130 Audio: Creating stream '[OSSAudio] Mic-In' returned an invalid backend configuration, skipping
00:00:07.073913 AC97: Reset
00:00:06.989808 ALSA: Using output device "default"
00:00:07.004405 ALSA: Failed to set period size 2400 (Invalid argument)
00:00:07.004472 ALSA: Using input device "default"
00:00:07.007188 ALSA: Failed to open "default" as input device: Operation not supported
00:00:07.007242 ALSA: Using input device "default"
00:00:07.010024 ALSA: Failed to open "default" as input device: Operation not supported
00:00:07.014107 AC97: Reset
(default snd device - HDMI out, so input err should ok)
I'd really like to see this fixed too. For various reasons I'd rather not have to pull in Pulseaudio and maintain local builds of Virtualbox. If there's anything I can do to keep it moving along.