Project

General

Profile

Bug #11353

OSS output module not working in VirtualBox

Added by Rick V about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:

Description

Selecting the OSS audio output in VirtualBox results in no audio in VMs
Selecting PulseAudio causes the input channel to irreversibly fall behind after long uptime or when the host is under load. Eventually Linux-only RTC apps (I currently run a Linux guest) become unusable due to exponentially increasing audio input delay.


Files

VBox.log (102 KB) VBox.log Rick V, 2019-07-06 10:59 PM

History

#1

Updated by Rick V about 1 month ago

Attached: a log with audio debug enabled, OSS module fails to create stream

00:00:59.945593 Audio: Requested host recording format for '[OSSAudio] Mic-In': 48000Hz, 16S, 2 Channels
00:00:59.945641 Audio: Using default period size (50ms, 2400 frames) for stream '[OSSAudio] Mic-In'
00:00:59.945653 Audio: Using default buffer size (250ms, 12000 frames) for stream '[OSSAudio] Mic-In'
00:00:59.945664 Audio: Using default pre-buffering size (250ms, 12000 frames) for stream '[OSSAudio] Mic-In'
00:00:59.955550 Audio: Stream '[OSSAudio] Mic-In' could not be created in backend because of missing hardware / drivers
00:01:00.284117 AC97: Setting Front DAC rate when VRA is not set is forbidden, ignoring

All other apps that use OSS work fine, and process audio input/output correctly

#2

Updated by Michal Nowak about 1 month ago

I hear some weird noises from time to time when PulseAudio is used. OSS isn't working for me as well, worst, the guest hungs periodically.

No change when I use VirtualBox compiled with VBOX_WITH_AUDIO_OSS.

No idea where to go from here.

#3

Updated by Garrett D'Amore about 1 month ago

250 ms is a long long time for a MIC input. 50 ms is even a little bit on the long side.

The other thing to realize that good working audio requires realtime level processing -- meaning threads have to wake promptly to keep the audio stream synchronized.

I think one of the bugs we have in the underlying illumos audio stack arises from assuming that timer interrupts will be handled promptly -- one of the major changes I made back in 2010 or thereabouts was the removal of the interrupt service routines for the audio drivers. The idea was to permit us to run without interrupts coming from the device drivers -- and to decouple us from hardware buffering sizes.

That was intended to facilitate follow up work (moving audio streams between devices, and nice Sun Ray audio to follow your session) that never actually occurred.

In retrospect, maybe we should have gone ahead and had the device specific audio interrupts after all. The physical chips on those devices run isochronously, and will wake with a real hardware interrupt with a fairly consistent guarantee -- but the system timer may run with a bit more slop (especially in a clockless configuration)

I know for certain that the timer interrupt thing was the main issue behind the VMware guest audio not working, and I restored that functionality ages ago, but only for virtualized devices. Maybe we should do that unconditionally.

You can see the work I did for this for audioens & VMware back in 2016 here: 5b1627536384deb03449347af9c01bd4fc2d271e

If people are wanting to use audio with illumos these days, I really should go back do this for those audio drivers people care about. Unfortunately, I no longer have access to most of the unusual audio chips -- I discarded my stock pile of random weird audio PCI cards several years ago.

Still, it seems like this could be done for the remaining mainstream audio devices -- audiohd and audioens. The only other remaining audio drivers are probably only interesting on SPARC desktops -- audiots, audio1550, and audiocs -- the latter is only used on Ultra-2 platforms!

#4

Updated by Rick V about 1 month ago

I'm using the USB Audio 1.0 driver since there doesn't seem to be a practical method of reassigning HD Audio output pins in software (Even OpenBSD has mixerctl(1)), and having the NVIDIA HD Audio driver loaded simply tends to complicate things a bit. (Why were the OSS apps such as ossinfo(1M) removed?)

Also available in: Atom PDF