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 fundamentals

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:

• A mixer that is used to control the levels of various inputs and outputs and to select the input used as the recording source. However this is an optional component that is missing from many devices. Even if there is a mixer it may be functionally entirely different than the mixers of some other devices.
• An Analog to Digital Converter (ADC) that converts the analog audio signal (from microphone or some device such as CD player) to digital format.
• A Digital to Analog Converter (DAC) that converts the digital data back to analog audio during playback.
• Some sound cards have also "digital" interfaces such as S/PDIF that are used to transfer audio signals between devices without doing redundant DA and AD conversions that could cause additional quality loss. Few devices have only digital inputs and outputs (no analog at all).
• In addition there may be all kind of effect/processing units.

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").

Audio fundamentals

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.

• Sampling rate defines how often the AD converter takes a new sample (measures the signal level). For example the CD audio records have been recorded using 44100 Hz (44.1 kHz) sampling rate which means that there are 44100 samples for each second. However 48 kHz is the most commonly used sampling rate in computer sound applications.

  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.

• Sample size (8, 16, 24 bits) defines the dynamic range that is possible in the signal. Dynamic range is the difference between the loudest and the weakest signal that can be recorded. The recording level is usually adjusted so that the peak volumes fit in the numeric range (don't clip). If the bit depth is low (8 bits) then the weakest signals may sound slightly distorted. Using higher bit depths make the "silent" moments to sound better. 16 bit sample size is the most commonly used one and it's suitable for most purposes. The 24 bit format is used in professional environments where the analog signal path has adequate signal quality.

  The 8 bit format is rarely used because today's computer systems ara capable to handle 16 bits equaally well.

• Number of channels defines how wide the sound field can be. In the mono format (1 channels) all the sound comes from one direction (single speaker or a virtual speaker somewhere between the other speakers). In the stereo format the sound sources are panned somewhere between two speakers. [!para The above two ones are the most common sound formats. In addition there are many kind of multi channel formats. For example 8 channels can be connected to a set of 8 speakers to play the 7.1 format that is the state of the art DVD multi channel format today. It's also possible that all the 8 channels are used to record from 8 different microphones at the same time.}

With OSS you can use the SNDCTL_DSP_CHANNELS, SNDCTL_DSP_SETFMT and SNDCTL_DSP_SPEED ioctl calls to set these parameters.

Which audio device to use

The audio devices in OSS are named as /dev/dsp0, /dev/dsp1, ..., /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:

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:

1. The application can use the SNDCTL_AUDIOINFO ioctl call to list the audio devices in the same way ossinfo.c does it. Then the user just picks the device from the list.
2. The application can ask the user to give the device file name(s) (such as /dev/dsp3 using some command line option or environment variable. A very simple approach is using an environment variable such as MYAPP_AUDIODEV, MYAPP_AUDIOINPUT or MYAPP_AUDIOOUTPUT (replace MYAPP_ with the name of your application).]
3. Use one of the default devices (see below). However it's recommended that such devices are only used as the "initial" values in the application config settings. The default device is common to all applications while many users want to use some device with given program while the remaining ones use the default. [!endenum

   The default devices

   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.

   • The forst list is used for applications that do playback only. OSS selects this list if the application used the 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.
   • The second list is for recording applications (O_RDONLY.
   • The third list is for duplex applications (O_RDWR.

   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).

   Dedicated default devices

   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.

   • /dev/dsp_ac3 is the default device for applications that want to use the AC3 passthrough method to play multi channel sounds. By default this device is assigned to the first audio device that supports this method.
   • /dev/dsp_multich Is the device to be used by applications wh like to play multi channel audio formats such as 5.1 or 7.1. However applications that do things like multi track hard disk recording/editing should use the numbered devices directly instead of this.
   • /dev/dsp_mmap should be used by applications (such as games) that use mmap to play audio.

   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.

   Obsolete audio devices

   OSS also creates a bunch of /dev/audio and /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 program

   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.

   
   

   ---

   Copyright (C) 4Front Technologies, 2007. All rights reserved.
   Back to index OSS web site