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

Device types supported by OSS

Open Sound System supports three kind of devices:

• Audio devices are used to play and record digital audio such as WAV or MP3 files. See the "Audio Programming" chapter for more info.
• Mixer devices are used to change volumes and all kind of "control panel" settings. See the "OSS Mixer Programming" chapter for more info.
• MIDI port devices are used to access musical instruments (keyboards, samplers and synthesizer modules) as well as to control various other devices such as mixers, effect processors, on stage lightning and pyrotecnics. See the "OSS MIDI Programming" chapter for more info

A typical computer sound card (or the motherboard sound subsystem) has one or more of these devices. The cheapest ones have just an audio device and a mixer. A typical system supports all of the types. Finally there are some highly sophisticated professional devices that have only MIDI or only digital audio without the other features.

OSS Supports several sound cards (in addition to the motherboard sound) which means that in the best case there may be tens of independent audio devices, few mixers and few MIDI ports.

All OSS devices are numbered. To find out the available device numbers you can execute the ossinfo utility. For example ossinfo -v1 prints something like following:

It's important to unserstand that there is no logic in the way how the numberings of these three device types are related with each other. It's common that the first mixer and audio devices belong together but this is often not the case. This is even more unlikely with the higher device numbers.

There is a method for matching the device numbers together but doing that doesn't make any sense. The audio API of OSS now has official ways for doing things like recording source selection and recording/playback volume control without accessing the mixer.

About device numbering

OSS device files have traditionally been named like /dev/dsp0, /dev/dsp1, ..., /dev/dspN with sequantial numbers. There have been no holes in the device numbering. Also the device numbers have been relatively static so it has been possible to save the numbers in application config files.

Due to modern technologies like device hot plugging/unplugging this is no longer true. This "legacy" device naming scheme is still supported by OSS but it's no longer reliable. For this reason the legacy naming should only be used by applications written for earlier OSS versions. It can also be used in scripts that use hardcoded device names.

Advanced device naming

Starting from OSS 4.0 the device numbering used by OSS is no longer static. Devices will be numbered in whatever order the operating system decides to initialize the devices. This means that device numbers may change every time OSS is restarted or the system is rebooted. In particular hot-pluggable devices such as USB or FireWire rarely get assigned the same numbers.

To solve the problems with initialization order OSS now uses device names which contain the device name. For example /dev/sblive0_pcm2 is the third audio device of the first SB Live!/Audigy card found in the system. This naming is completely static. The easiest way to find out the new style device names is to run ossinfo with verbosity level of -v1 or higher.

The exact naming scheme depends on the operating system. There is no guarantee that any given naming scheme will be used. For example the same device may be called as /dev/sblive0_pcm0 in some systems and /dev/sblive0/pcm0 or /dev/oss/sblive0/pcm0 in some others. Applications should not make any assumptions about the device naming system.

To maintain compatibility with older applications the ossdevlinks(1) utility is used to maintain "legacy" device numbers for the devices. The legacy device files (such as /dev/dsp0) are now symbolic links to the actual device file. OSS stores these links in /usr/lib/oss/etc/legacy_devices and they will be restored every time when OSS is restarted. When new devices are added to the system they will be given legacy device numbers after the previously installed devices. In this way the legacy device numbering will be relatively stable but system administrator may reset it by running ossdevlinks -r. For example /dev/dsp5 may be a symbolic link to /dev/sblive0_pcm2.

The /dev/sndstat file shows the devices in their legacy device order to maintain compatibility with some older applications. However new applications should not use /dev/sndstat to find out the device names. Instead they should use the programmatic method described below.

Obtaining device names programmatically

Applications should use the SNDCTL_SYSINFO ioctl call to find out how many audio, mixer or MIDI devices there are in the system. Then they can use SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO or SNDCTL_MIDIINFO to obtain the device name and the device node (devnode field) for each device. The device fila name returned in the devnode field can then be stored in the application config files. It is not recommended to try to guess the device names because future OSS versions may use different naming schemes. Please look at the ossinfo.c for an example of using the ioctl calls mentioned above.

Default devices

OSS provides default devices names for applications that don't have any config files. This makes using the applications very easy but the default files are not suitable for all kind of applications. The default device files supported by current OSS are the following (more names may be introduced in future OSS versions):

The most common default devices such as /dev/dsp, /dev/mixer and /dev/midi) will be available in all systems. However the remaining ones will only be created if there is a suitable device in the system.

It is recommended that applications using /dev/dsp check the OSS_AUDIODEV environment variable. If this variable is set then applications should use the device name specified by it instead of /dev/dsp. However device names given on command line or in the application setup should have priority over this. The same is true for OSS_MIXERDEV and /dev/mixer. Use of these environment variables makes it the applications to work better in many kind of virtualized environments where different users/sessions can have their private device sets.