Hannu’s Blog

Once upon a time OSS (VoxWare) was a pure audio device driver subsystem. An application using the API opened an audio device file (usually /dev/dsp) and it was given direct and exclusive access to the device. In addition the application could have opened /dev/mixer to control playback and recording volumes as well as to select the recording source (mic, line in, cd and so on).

It soon become apparent that this simple model doesn’t work well. The application was forced to support whatever sample rate or format the device supported. Use of /dev/mixer for volume control was not reliable because many devices used different volume control model than the usual consumer sound cards (such as Sound Blasters). Finally givin one application exclusive access to the device caused problems because the desktop manager kept the device open for it’s beeps and no other application was able to use it. The result was that each GUI subsystem implemented their own sound daemon (ESD, ARTSd) and all the other applications were forced to use such daemons instead of using the audio device directly.

The next step in development of OSS was addition of virtual mixing and automatic format conversions. In this way multiple applications were able to use the same physical audio device at the same time but only for playback. In addition existing applications still used /dev/mixer for their private volume control which caused serious conflicts between the application.

In OSS4 the API model got redefined. The API itself was kept unchanged so that any earlier applications were still compatible with it. Now most audio devices have virtual mixer (vmix) attached to them (by default or after attaching vmix using vmixctl attach). When the device is opened OSS will automatically redirect the application to the next free vmix engine of the device. Use of application/desktop specific audio mixing daemons is no longer necessary because any number of applications can share the device.

In the new audio API model applications no longer use devices directly. Instead they are now producers or consumers of audio streams. Whatever is the sample rate or format the application wants to play or record will be automatically handled by the vmix subsystem and the automatic rate/format conversions performed by the OSS audio core. Some new audio API (SNDCTL_DSP_*) ioctl calls were added so that applications can change stream related attributes such as volumes or recording sources without accessing the physical mixer. Some new pseudo audio drivers (such as oss_audioloop and oss_userdev) were added so that audio streams can be rerouted between applications and/or different systems.

As I said the API itself has remained unchanged. Most “properly written” OSS applications will work with the new model out of box. Some rare applications will still depend on the old direct-to-device model but the API gives them a way to bypass vmix and the automatic rate/format conversions.

As you probably know the audio subsystem to be used in Solaris will be Boomer. It’s a hybrid audio subsystem that supports both OSS and the older devaudio (SADA) audio interface of Solaris. Unlike OSS Boomer is based purely on the audio stream model.