Enter your search terms Submit search form   Web www.opensound.com manuals.opensound.com developer.opensound.com

Open Sound System OSS 4.x Programmer's Guide

Audio input and output volumes and routings

It's very important to understand that some audio devices (professional ones in particular) don't have any kind of control of this kind. Assuming this rom the device is a major error because it may unnecessarily prevent otherwise functional devices from being used with your application.

The ioctl calls described in this section are new in OSS 4.0 and earlier OSS versions will not have them. Applications using them must be prepared to handle the Possible error codes (errno) returned by OSS calls error returned in this kid of situations. The EINVAL error simply means that the device doesn't have such feature available. The application must handle this for example by removing the associated GUI elements (such as playback volume slider). In addtion in some cases the values may be locked to some value and it may refuse to change. This is perfectly normal and the application must not consider it as an error. The application must in no case refuse to work if any of these features are missing.

There is a large number of "consumer" sound cards (or motherboard sound subsystems) that are similar to some of the first sound cards that were available during early 1990's. Such simple devices had one recording engine that was able to select between certain input jacks such as microphone, line in, CD-audio or possibly few others. Equally well they had sliders for changing things like main volume, audio/wave/pcm playback device and recording volume. Some more "advanced" ones had even settings for the bass and treble levels of the output.

Some popular audio applications written in early 90's decided to add support for some of these "legacy" mixer features. This tradition has been followed by other applications that have copied the same design. Unfortunately this approach has been causing some problems for years with devices that are even slightly different than the one the application was originally tested with.

Some reality

While most consumer devices still follow this convention there has also been some professional audio devices that are entirely different. For example there are devices that break the legacy mixer model in the following ways:

• Digital only (S/PDIF AES/EBU) devices don't usually have any volume control at all. The whole idea of such digital interfaces is that the signal is passed unmodified between the devices to avoid any quality losses. Adding volume control to this kind of links breaks the whole idea.
• Most professional devices have just one input. Alternatively they have dedicated recording engines for all inputs. For this reason there is no recording source selection. Or the input port is selected simply by openeing the right /dev/dsp# device directly.
• There are also devices that have full blown on board mixers that permit routing and mixing the signals between inputs, outputs and applications in every imaginable way. It's simply impossible to map this kind of huge interfaces to any mixer API so that it's manageable by any applications.
• Having predefined input or output names such as mic, line, aux, speaker and headphones is very inflexiple. In reality there are also "physical" input names such as in1/2, out1/2, send1, send2, busA and monitor. To make the things even more complicated it's possible that the user can assign different names to the inputs and outputs on fly.

The OSS way

To make handling of audio inputs and outputs as transparent as possible we have added a set of new ioctl calls to the audio API of OSS:

Purpose	Ioctl calls to use
Play volume	You can use the SNDCTL_DSP_SETPLAYVOL and the SNDCTL_DSP_GETPLAYVOL ioctl calls to set/get the playback volume level for this particular audio device. THis replaces the SOUND_MIXER_PCM method used by earlier audio applications.
Record volume	You can use the SNDCTL_DSP_SETRECVOL and the SNDCTL_DSP_GETRECVOL ioctl calls to set/get the recording volume level for this particular audio device.
Record source	The SNDCTL_DSP_GET_RECSRC, SNDCTL_DSP_SET_RECSRC and SNDCTL_DSP_GET_RECSRC_NAMES ioctl calls to find out the possible recording source names and select one of them as the active source. The recsrc.c sample program demonstrates how to do that.
Playback routing	The SNDCTL_DSP_GET_PLAYTGT, SNDCTL_DSP_SET_PLAYTGT and SNDCTL_DSP_GET_PLAYTGT_NAMES ioctl calls to find out the possible playback routing names and select one of them as the active target. However please note that most devices don't have selectable output routings. There is no sample program for this but the recsrc.c one can be easily modified for this purpose just by changing the ioctl calls from RECSRC ones to PLAYTGT.

To use the playback volume and target control calls the audio device must have been opened with O_WRONLY or O_RDWR. Equally well the recording source and level control is only possible if the device is opened with O_RDONLY or O_RDWR.

Also note that the recording source and play target names may change on fly. This mechanism is described in the manual pages for these calls (see the links above. This feature makes it possible to automatically distribute input/output assignment information to various applications without need to remember what was the input 7 used for or which of the outputs was connected to the backstage monitor or to the loudspeaker in the entrance hall.