[Top] [Prev] [Next]

audio - interface to audio devices

bind -a '#A' /dev



The audio device provides kernel support for an interface to a variety of sound devices. Some of the things you can do with the audio device are:

audio device file - audio

The audio device file audio is used to send or receive raw audio data. Data read or written to the audio file are processed as raw information in the format described by the current state of the control file audioctl. The audio file does not support any file format conventions. It is the responsibility of the application to read or write audio data to or from files in a suitable format.

Write to audio

The data written to audio are output to the assigned output device. The default audio output device is a speaker(s). Other output devices include headphones, line-out, and similar devices.

If the application writes to the audio file faster than the buffer sends it to the output, the application blocks until there is enough internal memory to hold the incoming data.

Read from Audio

The data read from audio is input from the assigned input device. The default audio input device is a microphone.

The microphone input begins at the first read request and ends at close, or until the internal buffers are full. A subsequent read will then start the input again.


The input may end if the read is not fast enough. This may lead to dropped data samples.

audio control file - audioctl

The audio control file (audioctl) is used to send or receive formatted audio control messages. Control messages read or written to the audioctl file modify the processing of raw data read or written to the audio file.

The audioctl file settings are persistent across process invocations. An application running on Inferno should query the capabilities of the local audio device before utilizing any audio services. An application should prepare the audio file for output by sending the appropriate message to the audioctl file prior to reading or writing data.

Valid messages written to the audioctl file using the write system call return a non-zero value equal to the length of the ASCII message string. Invalid messages written to the audioctl file using the write system call return a value equal to -1.

Applications reading from the audioctl file should supply a buffer of size AUDIO_INFO_MAX (512). The returned string from reading audioctl contains the supported type strings along with all the acceptable values for that type. The first value following the type is the current value. The returned string can then be tokenized using system calls and processed appropriately.

Messages to ctl

Application messages sent to the audioctl file behave differently for input and output.

Messages sent to the audioctl file to control output, block the process until any existing raw data in the audio file has been played. The state of the audio file output processing is then modified so that new raw data written to audio will play appropriately.

Messages sent to the audioctl file to control input result in flushing any unread raw input data in the audio file. The state of the audio file input processing is then modified so that new raw data read from audio will match the new input control settings.

The messages sent to or received from the audioctl file are ASCII-based text messages following the syntax:

[dir] type value [type value1 value2 value3]


The option dir can be either in or out if an application wishes differing configuration for input and output.

type value

A variable number of tuples consisting of type value(s) are accepted and/or returned. If multiple values for a given type are used, the first value (value1) represents the assigned control value for that type. Values are specific to the type identifier. All types and values are supplied as ASCII text separated by white space, tab stops, new-lines, or commas.

The types and their acceptable values are listed as follows:

enc - encoding format

µ-law encoding


A-law encoding


Pulse Code Modulation encoding

rate - sampling rate

8000 samples per second


11025 samples per second


22050 samples per second


44100 samples per second

chans - channels

1 channel


2 channels

bits per encoding sample

8 bits per sample


16 bits per sample

buf - play/record sample buffer size
0 - 100

Any whole number between 0 and 100 representing the percentage between the minimum and maximum buffering capability.

count - number of samples waiting for I/O

flush in/out.


number of samples waiting for I/O

dev - input device

input microphone

dev - output device

output speaker


There are two audio device files supported on any Inferno platform regardless of the number of physical audio devices or the number of applications which access the audio facilities. In this release, only one application can read and/or write to the audio device since mixing is not currently supported.

A write to the audio file means your data has been queued to play but does not mean it has completed playing (sound may linger and continue although your write succeeds).

When your application closes down, the close will block until all queued data has been played on the speakers

To read or write audio data over a network, first cross mount to another machine and then read or write to the other machine.

On Win95 and Win NT, mute your microphone first so you don't hear your echo

[Top] [Prev] [Next]

Copyright © 1996,Lucent Technologies, Inc. All rights reserved.