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

Supported audio formats

The number of different sample formats may look large but fortunately just very few of them are used in real world systems. The others are defined just for completeness or to be used for some very specific purposes.

Actually most applications need to support just a 16 bit data format. OSS can convert it to any other format if necessary. The only exception is applications that use mmap. Such applications are entirely on their own and they must be able to support practically all sample formats themselves. Otherwise such applications will never work with all sound cards.

The most recommended choices to be used as the sample format in applications are AFMT_S16_NE or AFMT_S16_LE. These formats are actually exactly the same in the normal PC systems that use little endian memory architecture. However there is a minor conceptual difference. See the Handling endianess of samples section for more info.

The early ancestors of OSS only supported one 8 bit sample format and one 16 bit one. Later it appeared to be necessary to support more sample formats and the the AFMT_* scheme was introduced. For compatibility the numeric value of AFMT_S16_LE format is 16 and the AFMT_U8 format is 8 because these two formats match the origibal sample sizes. However this is not true with 24, 32 or any other sample sizes.

The numbers for the AFMT_ sample formats have been selected so that each format takes one of the 32 bits of an int variable. In this way it's possible to implement sample format sets very easily. For example the set of the sample formats supported by a device can be stored in one 32 bit integer.0

Channel interleaving and data rate

One channel (mono) audio data streams can be handled as an array of some data type (such as unsigned char, signed short or signed int. Samples will be simply stored one after other in the order they were recorded.

In multi channel data streams (2 or more channels) will be stored using a method called interleaving. For example in two channel (stereo) data streams the first array element will contain the channel 1 (left) sample for the first sample period. The second element contains the first sample for channel 2 (right). After that come the left and right samples for the second sample period and so on.

The pair of left+right samples (or a tuple of samples for all channels) is called frame. The size of the frame depends on the sample size and the number of channels. The frame size of the usual 16 bit stereo format is 2*2=4 bytes (32 bits). If the sampling rate is 48 kHz there will be 48000 frames every second. This gives data rate of 4*48000=192000 bytes per second.

Some sample formats such as AC3 or MPEG are encoded bit streams. Even there may be multiple channels in such bit streams the samples are not interleaved and it's not possible to pick individual samples from the stream without using very sophisticated decoding algorithms.

Linear vs non-linear formats

Linear sample formats

Linear sample formats are easy to use because the processor can usually do computations on these formats without any conversions. The only exception is the "de facto" 8 bit data format which is unsigned for historic reasons (the original Sound Blaster card used this format). Linear means that the sample value is directly the sound level as measured by the analog to digital converter (ADC). The following formats use linear encoding.

The first sound cards in the market supported only 8 bit sample resolution so the 8 bit format was earlier very common. They are not recommend in new applications since many recent sound devices don't support 8 bits any more. However it's still recommended to use 8 bits when playing old 8 bit audio files.

The C/C++ language doesn't define exactly how many bits are allocated for different kind of types. This document uses int, short and unsigned char because they will map to the right 32/24, 16 and 8 bit data types in all architectures OSS is available. However it might be a good idea to use types like int32_t, int16_t and uint8_t (uchar) for greater portability. There are some other systems where int is still 16 bits and long is used for 32 bits (for historic reasons). The "long" type should be avoided because it's 32 bits in some systems and 64 bits in the others.

The 16 bit formats are most commonly used in computer audio applications. Practically all audio devices support this resolution and this is the de facto standard in consumer devices.

The 24 bit formats are currently supported only by audio devices designed for professional use. There are actually two kind of 24 bit formats. Both of them use 32 bit integers (int) but the value is aligned in different way.

The 24/32 bit LSB aligned formats store a 24 bit sample in the 24 least significant bits so the numeric range is between -16777216 and 16777215. This format is good as an internal data format in applications because it's more immune to computing overflows. However devices rarely support this format directly.

The 32 bit MSB aligned formats use the full numeric range of a 32 bit integer. Most 24 bit devices use this format but ignore the least significant 8 bits. The benefit of this format is that it will be compatible with future devices with more than 24 bits of resolution. However it's rather unlikely that audio devices ever support such formats. This format may be difficult to use in applications because there is no room for overflows.

In general it doesn't matter which 24 bit format the application uses. OSS can convert between the different types. However applications that use mmap need to be prepared to support any of them.

Logarithmic sample formats

The following two formats use logarithmic scale to store 12 bit samples in 8 bit bytes. More bits are allocated for the low sound levels which gives slightly better sound quality than the linear 8 bit format. With todays technology there is no need to use these formats (or the 8 bit ones). They are supported by oss just for compatibility reasons. Applications should not use them any more. There are superior audio compression algorithms for applications that need very low bandwidth.

Block encoded formats

The following sample formats use highly sophisticated (lossy) encoding algorithms to pack audio data to very small amount of memory. All these formats require special algorithms and some of them are patented. Describing them is outside the scope of this manual.

Some odd formats

Finally there are few audio data formats supported by OSS that are hard to classify or actually never used. They may have some future (behind) but at this moment programmers don't need to care about them.