Open Sound System
|Do you have problems with sound/audio application development? Don't panic! Click here for help!
In short computer digital audio means converting audio signals to a series of numbers and storing them in a computer for playback (sooner or later).
A typical audio card (or the audio subsystem of a sound card) consists of one or more of the following components:
Even the mixer functionality was listed above it actually doesn't belong to the audio programming chapter. Mixer programming will be explained in the "OSS Mixer Programming" programmin chapter. However the most commonly used mixer functions have now be included directly in the audio programming API so there is no need to access the mixer just to select the recording source or to alter the recording or playback level.
The MIDI functionality is completely independent from audio. It's covered in it's own chapter ("OSS MIDI Programming").
OSS 4.0 differs from the earlier OSS versions (as well as the freeware clone versions based on them) because now the application doesn't any more be worried about any characteristics of the device. Instead it just tells OSS what kind of audio stream it wants to record or play. OSS will then take care of the rest and ensure that the device handles the stream correctly.
There are three key parameters of digital audio streams that are pretty much everything the application needs to set.
The right sampling rate to use depends on the signal being recorded. In general the sampling rate must be two times (or bit more) higher than the upper limit of the frequency range of the input. Using too high sampling rate doesn't make any significant improvement to the sound quality because the input signal doesn't contain any upper frequencies.
The 8 bit format is rarely used because today's computer systems ara capable to handle 16 bits equaally well.
With OSS you can use the SNDCTL_DSP_CHANNELS, SNDCTL_DSP_SETFMT and SNDCTL_DSP_SPEED ioctl calls to set these parameters.
The audio devices in OSS are named as
/dev/dsp63. However in typical systems there are not that many devices available. The easiest way to find out what devices are available is using the ossinfo
command. For example the
ossinfo -a command produces the following output in one system:
Audio devices (/dev/dsp*)
0: M Audio Delta 1010LT out1/2 (audio port 0 of card 0)
1: M Audio Delta 1010LT out3/4 (audio port 2 of card 0)
2: M Audio Delta 1010LT out5/6 (audio port 4 of card 0)
3: M Audio Delta 1010LT out7/8 (audio port 6 of card 0)
4: M Audio Delta 1010LT S/PDIF out (audio port 8 of card 0)
5: M Audio Delta 1010LT in1/2 (audio port 10 of card 0)
6: M Audio Delta 1010LT in3/4 (audio port 12 of card 0)
7: M Audio Delta 1010LT in5/6 (audio port 14 of card 0)
8: M Audio Delta 1010LT in7/8 (audio port 16 of card 0)
9: M Audio Delta 1010LT S/PDIF in (audio port 18 of card 0)
10: M Audio Delta 1010LT input from mon. mixer (audio port 20 of card 0)
11: M Audio Delta 1010LT (all outputs) (audio port 0 of card 0)
12: M Audio Delta 1010LT (all inputs) (audio port 10 of card 0)
13: M Audio Delta TDIF out1/2 (audio port 0 of card 1)
14: M Audio Delta TDIF out3/4 (audio port 2 of card 1)
15: M Audio Delta TDIF out5/6 (audio port 4 of card 1)
16: M Audio Delta TDIF out7/8 (audio port 6 of card 1)
17: M Audio Delta TDIF S/PDIF out (audio port 8 of card 1)
18: M Audio Delta TDIF in1/2 (audio port 10 of card 1)
19: M Audio Delta TDIF in3/4 (audio port 12 of card 1)
20: M Audio Delta TDIF in5/6 (audio port 14 of card 1)
21: M Audio Delta TDIF in7/8 (audio port 16 of card 1)
22: M Audio Delta TDIF S/PDIF in (audio port 18 of card 1)
23: M Audio Delta TDIF input from mon. mixer (audio port 20 of card 1)
24: M Audio Delta TDIF (all outputs) (audio port 0 of card 1)
25: M Audio Delta TDIF (all inputs) (audio port 10 of card 1)
This system is a typical professional one that has two (or more) sound cards which each have multiple devices. Some of them are inputs and some others are outputs. There may also be devices than can be used in both directions. In addition there are some devices (11, 12, 24 and 25) that are redundant with some other ones (for example 11 is actually a multi channel device that handles the stereo channel pairs 0 to 4 together. It's possible to use devices 0 to 4 at the same time. However none of them can be used at the same time with 11.
There are more such nasty special cases and for this reason we do not recommend using any AI algorithm for selecting the devices automatically. Instead applications should shjow the available devices and let the user to select the ones to be used.
There are three possible device selection strategies:
/dev/dsp3 using some command line option or environment variable. A very simple approach is using an environment variable such as
MYAPP_ with the name of your application).]
Old OSS developers may have wondered why the
/dev/dsp device was not mentioned above. The reason is simple. The purpose and usage of this device has changed slightly since the previous OSS versions.
In early OSS (actually it was not called OSS at that time) versions there was only one audio device that was
/dev/dsp. Later it became possible to have multiple audio devices in the same system and
/dev/dsp1 was assigned to the second one and so on. Some Linux distributions still follow this naming scheme which may cause some compatibility problems with them.
Years later the first device was renamed to
/dev/dsp0 which is a logical solution. The
/dev/dsp device was now created as a symbolic link that points to one of the "real" devices (/dev/dsp0 to /dev/dsp63) depending on the needs of the application.
The above approach is still in use under most operating systems. However under Linux and Solaris it was possible to implement
/dev/dsp as a very special special device. In these environments
/dev/dsp is no longer a symbolic link the user should set. Instead the Bad xlink 'ossctl' program is now used to control the way how this device behaves.
There are three different device lists that can be freely modified. If the first device on the list is free then it will be opened when some application tries to open
/dev/dsp. However if the device was busy (used by some other application) then the next devices on the list will be tried until a free one is found. In this way it's possible to get multiple applications to do audio at the same time.
O_WRONLY flags when opening the device. By default this list has the virtual mixer devices in the front so they will be assigned first.
Note that the default device logic doesn't work with applications that are going to use the mmap method for audio playback. The reason is that mmap application (in Linux at least) must open the device with O_RDWR instead of O_WRONLY. This makes the redirection logic to use the wrong list. This causes problems with some devices. Applications using mmap should use the "numbered" devices directly or the default mmap device (see below).
OSS 4.0 creates some additional default devices for few common application types. These are just symbolic links in the current OS versions but they can be handled differently in the future.
Use of these dedicated devices is recommended as the default devices in applications listed below. In this way the user can assign a different devices for this kind of special applications.
These devices files don't exist in pre OSS 4.0 systems. The application can ask the user to create the right symbolic link if necessary. Alternatively it can just silently divert to /dev/dsp if the device is missing.
OSS also creates a bunch of
/dev/dspW device files. They are no longer part of oss and must in no case be used by OSS compatible programs. They are created just because some older applications may still depend on them.
Writing a simple audio playback or recording application is extremely easy. All you need to do is opening the right audio device, setting the three most fundamental parameters and then just reading or writing.
The singen.c program is a good example of a program that does audio playback.
Using OSS for more challenging purposes will be explained elsewhere in this manual. For example in the Some common types of audio programs section.