Feb. 3, 2003, Copyright (c) Takashi Iwai <email@example.com>
ALSA provides a
powerful OSS emulation on the kernel.
The OSS emulation for PCM, mixer and sequencer devices is implemented
as add-on kernel modules,
When you need to access the OSS PCM, mixer or sequencer devices,
the corresponding module has to be loaded.
For loading these modules automatically, define the aliases in
/etc/modules.conf like below:
alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss
Then the access to an OSS device file such as
/dev/dsp0 triggers to load the necessary module via
For auto-loading the secondary card device like
/dev/dsp1, the following aliases are necessary in
alias sound-service-1-0 snd-mixer-oss alias sound-service-1-3 snd-pcm-oss alias sound-service-1-12 snd-pcm-oss
Here you don't need to define
service-1-8 because there is only one sequencer
device. Similarly, you can add definitions for the third or
later cards as
The OSS-MIDI is emulated directly in the ALSA rawmidi module, therefore no extra module exists for that purpose.
The currently available OSS configuration is shown in
/proc/asound/oss/sndstat. This shows in the same
/dev/sndstat, which is available on the
commercial OSS driver. On ALSA, you can symlink
/dev/sndstat to this proc file.
Please note that the devices listed in this proc file appear only after the corresponding OSS-emulation module is loaded. Don't worry even if "NOT ENABLED IN CONFIG" is shown in it.
ALSA supports the following OSS device files:
NOTE: Some distributions have the device files like
/dev/midi1. They are
NOT for OSS but for tclmidi, which is
a totally different thing.
Unlike the real OSS, ALSA cannot use the device files more than the
assigned ones. For example, the first card cannot use
/dev/dsp2, but only
As seen above, PCM and MIDI may have two devices. Usually, the first
PCM device (
hw:0,0 in ALSA) is mapped to
/dev/dsp0 and the secondary device
/dev/adsp0 (if available).
for the first and second devices, respectively.
You can change this device mapping via the module options of
snd-rawmidi. In the
case of PCM, the following options are available for
/dev/dspX (default = 0)
/dev/adspX (default = 1)
For example, to map the third PCM device (
/dev/adsp0, define like this:
options snd-pcm-oss adsp_map=2
The options take arrays. For configuring the second card,
specify two entries separated by comma. For example, to map the
third PCM device on the second card to
define like below:
options snd-pcm-oss adsp_map=0,2
To change the mapping of MIDI devices, the following options are
/dev/midi0X (default = 0)
/dev/amidi0X (default = 1)
For example, to assign the third MIDI device on the first card to
/dev/midi00, define as follows:
options snd-rawmidi midi_map=2
As default, ALSA emulates the OSS PCM with so-called plugin layer, i.e. tries to convert the sample format, rate or channels automatically when the card doesn't support it natively. This will lead to some problems for some applications like quake or wine, especially if they use the card only in the MMAP mode.
In such a case, you can change the behavior of PCM per application by
writing a command to the proc file. There is a proc file for each PCM
where X is the card number (zero-based), Y the PCM
device number (zero-based), and
p is for playback
c for capture, respectively. Note that this
proc file exists only after
snd-pcm-oss module is
The command sequence has the following syntax:
app_name fragments fragment_size [options]
app_name is the name of application with (higher
priority) or without path.
fragments specifies the number of fragments or zero
if no specific number is given.
fragment_size is the size of fragment in bytes or
zero if not given.
options is the optional parameters. The following
options are available:
The disable option is useful when one stream direction (playback or capture) is not handled correctly by the application although the hardware itself does support both directions. The direct option is used, as mentioned above, to bypass the automatic conversion and useful for MMAP-applications. For example, to playback the first PCM device without plugins for quake, send a command via echo like the following:
% echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss
While quake wants only playback, you may append the second command to notify driver that only this direction is about to be allocated:
% echo "quake 0 0 disable" > /proc/asound/card0/pcm0c/oss
The permission of proc files depend on the module options of snd. As default it's set as root, so you'll likely need to be superuser for sending the command above.
The block and non-block options are used to change the behavior of
opening the device file.
As default, ALSA behaves as defined in POSIX, i.e. blocks the file
when it's busy until the device becomes free (unless
O_NONBLOCK is specified). Some applications assume
the non-block open behavior, which are actually implemented in
some real OSS drivers.
This blocking behavior can be changed globally via
nonblock_open module option of
snd-pcm-oss. For using the non-block mode as
default for OSS devices, define like the following:
options snd-pcm-oss nonblock_open=1
You can check the currently defined configuration by reading the proc file. The read image can be sent to the proc file again, hence you can save the current configuration
% cat /proc/asound/card0/pcm0p/oss > /somewhere/oss-cfgand restore it like
% cat /somewhere/oss-cfg > /proc/asound/card0/pcm0p/oss
Also, for clearing all the current configuration, send
erase command as below:
% echo "erase" > /proc/asound/card0/pcm0p/oss
Since ALSA has completely different mixer interface, the emulation of
OSS mixer is relatively complicated. ALSA builds up a mixer element
from several different ALSA (mixer) controls based on the name
string. For example, the volume element
SOUND_MIXER_PCM is composed from "PCM Playback
Volume" and "PCM Playback Switch" controls for the playback
direction and from "PCM Capture Volume" and "PCM Capture Switch"
for the capture directory (if exists). When the PCM volume of
OSS is changed, all the volume and switch controls above are
As default, ALSA uses the following control for OSS volumes:
OSS volume ALSA control Index ----------------------------------------------------- SOUND_MIXER_VOLUME Master 0 SOUND_MIXER_BASS Tone Control - Bass 0 SOUND_MIXER_TREBLE Tone Control - Treble 0 SOUND_MIXER_SYNTH Synth 0 SOUND_MIXER_PCM PCM 0 SOUND_MIXER_SPEAKER PC Speaker 0 SOUND_MIXER_LINE Line 0 SOUND_MIXER_MIC Mic 0 SOUND_MIXER_CD CD 0 SOUND_MIXER_IMIX Monitor Mix 0 SOUND_MIXER_ALTPCM PCM 1 SOUND_MIXER_RECLEV (not assigned) SOUND_MIXER_IGAIN Capture 0 SOUND_MIXER_OGAIN Playback 0 SOUND_MIXER_LINE1 Aux 0 SOUND_MIXER_LINE2 Aux 1 SOUND_MIXER_LINE3 Aux 2 SOUND_MIXER_DIGITAL1 Digital 0 SOUND_MIXER_DIGITAL2 Digital 1 SOUND_MIXER_DIGITAL3 Digital 2 SOUND_MIXER_PHONEIN Phone 0 SOUND_MIXER_PHONEOUT Phone 1 SOUND_MIXER_VIDEO Video 0 SOUND_MIXER_RADIO Radio 0 SOUND_MIXER_MONITOR Monitor 0
The second column is the base-string of the corresponding ALSA control. In fact, the controls with "XXX [Playback|Capture] [Volume|Switch]" will be checked in addition.
The current assignment of these mixer elements is listed in the proc
which will be like the following
VOLUME "Master" 0 BASS "" 0 TREBLE "" 0 SYNTH "" 0 PCM "PCM" 0 ...where the first column is the OSS volume element, the second column the base-string of the corresponding ALSA control, and the third the control index. When the string is empty, it means that the corresponding OSS control is not available.
For changing the assignment, you can write the configuration to this proc file. For example, to map "Wave Playback" to the PCM volume, send the command like the following:
% echo 'VOLUME "Wave Playback" 0' > /proc/asound/card0/oss_mixer
The command is exactly as same as listed in the proc file. You can change one or more elements, one volume per line. In the last example, both "Wave Playback Volume" and "Wave Playback Switch" will be affected when PCM volume is changed.
Like the case of PCM proc file, the permission of proc files depend on the module options of snd. you'll likely need to be superuser for sending the command above.
As well as in the case of PCM proc file, you can save and restore the current mixer configuration by reading and writing the whole file image.
Note that when attempting to use a single device file for playback and capture, the OSS API provides no way to set the format, sample rate or number of channels different in each direction. Thus
io_handle = open("device", O_RDWR)will only function correctly if the values are the same in each direction.
To use different values in the two directions, use both
input_handle = open("device", O_RDONLY) output_handle = open("device", O_WRONLY)and set values for the corresponding handle.
ICE1712 supports only the unconventional format, interleaved 10-channels 24bit (packed in 32bit) format. Therefore you cannot mmap the buffer as the conventional (mono or 2-channels, 8 or 16bit) format on OSS.
Some USB devices support only 24bit format packed in 3bytes. This format is not supported by OSS and no conversion is provided by kernel OSS emulation. You can use the user-space OSS emulation via libaoss instead.