OSS output module not working in VirtualBox
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.
Updated by Rick V about 1 year 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
Updated by Garrett D'Amore about 1 year 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!
Updated by Rick V about 1 year 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