Audio support in HP MPower - computer network communications software - includes related article on analog-to-digital signal conversion

Hewlett-Packard Journal, April, 1994 by Ellen N. Brandt, Thomas G. Fincher, Monish S. Shah

The sampling rate is also subject to the Nyquist criterion, which dictates that the sampling rate must be at least twice the rate of the highest frequency being recorded. Higher frequencies will typically be filtered out by the recording hardware.

Multiple Channels. Although audio files with more than two channels do exist, most are either mono (one channel) or stereo (two channels). The two channels in a stereo file are typically interleaved on a sample by sample basis. This means there will be a sample for the left channel, followed by one for the right, followed by the next one for the left and SO on.

Byte Ordering. One problem with supporting files across a heterogeneous environment is that the byte ordering of the local hardware may be different. In our audio structure we supply information about the byte ordering of the audio hardware connected to the system. Unfortunately, there is no easy way to determine the byte ordering of the audio data in a file that is imported from elsewhere. Therefore we are forced to make assumptions. We assume all RIFF/Waveform files use least-significant-byte-first order and that all other files use most-significant-byte-first order. This applies even to the files created by our audio tools.

Client/Server Architecture

The audio system software uses a client/server architecture that is modeled after the X Window System (see Fig. 2). The client side provides a consistent interface to application programs and handles the connection to the server, which may be local or remote. The server side provides a consistent interface to the client side, handles control of the audio device, and performs data I/O.

The audio server (aserver) interfaces multiple clients to the audio hardware, allowing simultaneous play and record, queuing of multiple play and record transactions, priority preemption, and dynamic buffering.

The audio server also supplies information to the client side about the attributes of the connected audio hardware. The audio library provides the capability to convert various audio attributes to ones that are supported by the connected hardware. Therefore, the hardware attributes (sampling rates, data formats, byte ordering, etc.) do not need to be the same on the client and the server.

Support for Application Developers

Since our audio software subsystem is closely modeled after the X Window System and OSF/Motif, we provide a library, a server, widgets, and a toolkit that are very similar to their X counterparts. When appropriate, we followed the X conventions in our implementation of the various components. For example, the naming convention, function argument convention, and event and error handling of the audio library all follow the conventions used in Xlib. An application developer who is familiar with X and OSF/Motif should fmd it easy to incorporate audio functionality.

The audio server handles the interface to the audio driver and provides control of audio transactions. This isolates the audio client from hardware-specific device calls and allows a higher level of transaction control than would otherwise be possible.