Google
 

Open Sound System
OSS 4.x Programmer's Guide

Do you have problems with sound/audio application development? Don't panic! Click here for help!

When OSS audio ioctl calls can be made

The audio devices (both input and output) may be in different states depending on what the application has done after opening the device. There are some differences on the way how ioctl calls work. Call made in a wrong place is likely to cause unexpected effects. This section defines which ioctl calls can be made and when. In addition there are some ioctl calls that don't have any restrictions on when they are used.

The application should first make ioctl calls that belong to the first state (there is no need to call any of them). The device will move to some of the subsequent states as soon as any of the calls defined for it have been called.

It's not possible to use calls that belong to the previous states. Such calls may fail or they just don't have any effect.

Initial state

After the device has been opened it's in the initial state. Everything is stopped. The sampling rate and the other parameters have been set to some default values. There are few calls that can only be made in this moment.

Device setup state

In this state the application sets the number of channels, sample format and sample rate. The changes to these three parameters cannot be made later. They don't have any effect when the device is running. Calling read/write or any ioctl call that report the fragment size will lock the sampling rate.

After recordin/playback has been started it's possible to change the sample rate and format after calling SNDCTL_DSP_HALT, SNDCTL_DSP_HALT_OUTPUT and/or SNDCTL_DSP_HALT_INPUT). However this is not recommended because some devices may not support this. It's better to close and re-open the device before changing these parameters.

With some ancient sound devices (SB Pro) it was necessary to set these parameters in order: channels, format and rate. OSS doesn't support such devices any more so this restriction can be relaxed. However it's still possible that some other OSS implementations support them so use this recommendation if you don't have any good reason to do it otherwise.

The following calls can also be used in this state. There are no ordering restrictions between them.

Ready for startup state

The ioctl calls that belong to this class cause certain internal parameters to be locked. In particular the fragment size gets computed.

Running state

The device gets started if any of the following calls are made.

The following calls will return meaningful results only when the device is running. In the other states they may return values that are confusing.

For example the SNDCTL_DSP_GETISPACE call will tell that the there is nothing that can be read. This means that applications that blindly wait for something to become available will just sit there forever. The select call will not report any read events if the recording process has not started.

The following two ioctl calls don't have any effect if playback is not running.

Stopping the device

The following ioctl calls should only be used when the device is being stopped. However normally applications just call close at the end without using these calls.



Copyright (C) 4Front Technologies, 2007. All rights reserved.
Back to index OSS web site