| | Open Sound System |
| Do you have problems with sound/audio application development? Don't panic! Click here for help! |
audio_buf_info bi;
ioctl(fd, SNDCTL_DSP_GETISPACE, &bi);
The above code fragment lacks all error checks for clarity. Real world applications must always check for the errors and handle them as described below. Also most OSS ioctl calls will return information in the argument variable and it's usually necessary to check it too.
This ioctl call is out of fashion. Development of OSS has made it unnecessary in new applications. There is rarely need to avoid blocking in normal applications.
This ioctl call can be used to check how many bytes can be read from the device without blocking. See the Audio timing considerations section for more info about audio timing and syncronization.
Another purpose is to get the "optimal" fragment size to be used by the application. Please see the discussion about fragment sizes in the decomentation of SNDCTL_DSP_GETOSPACE.
It's very important to understand that this call is not designed to be used for syncronizing the screen content (video/visualizations/game) with audio.
The audio_buf_info field contains the following fields:
bytes returns the number of bytes that can be read without blocking. fragments (obsolete) returns the number of full fragments that can be read without blocking. fragsize is the current fragment size in recording direction. fragstotal is the number of buffer fragments allocated for recording. This ioctl must in no case be called before the device setup is finished.
It's normally not desirable to avoid blocking. Using blocking writes and reads is the most optimal way of doing syncronization. Non-blocking operation is significantly more difficult to use and in many case just consumes more resources. In particular non-blocking operation must not be used if it results in a wait loop before read/write.
It's very important to understand that this ioctl call will return bytes=0 before the recording process has been started. It's necessary to start recording by calling read() or SNDCTL_DSP_SETTRIGGER. If this is not done then the application will probably hang forever waiting for the recording to start.
Possible sample rate and/or sample format conversions being made by the driver will affect the values returned by this call. In such case some of the fields may seem to be inconsistent with the information returned by some ofter calls. This is not an error but may break applications that use this call for purposes it's not designed for.
Please look at the When OSS audio ioctl calls can be made section for information about DSP ioctl call ordering.
The return value from the OSS ioctl calls will be -1 if a fatal error occurred. Other values mean that the ioctl call was more or less successful. However in most cases the application must check the value returned in the argument to see what was the accepted value.
Please see the Possible error codes (errno) returned by OSS calls section for more info about the error codes returned by OSS.
| fulldup.c | Full duplex sample program using the single device approach. |
| mmap_duplex.c | A simple sample program for doing dull duplex using mmap |
| mmap_test.c | A sample program for using mmap() |
| dsp_geterror_demo.c | A simple demonstration of |
| seltest2.c | This program has been used to verify that the select() call works |
| iosync.c | Measuring the hardware level latencies. |
| ioctl_test.c | This program has been used to verify that some of the ioctl calls work |