| | Open Sound System |
| Do you have problems with sound/audio application development? Don't panic! Click here for help! |
oss_mixer_enuminfo namelist;
ioctl(fd, SNDCTL_DSP_GET_RECSRC_NAMES, &namelist);
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.
The following fields are available in the oss_mixer_enuminfo structure returned by this call.
nvalues returns the number of possible routings (1 to N). version returns a time stamp. If the time stamp is 0 then the label assignmet is static (will not change before the device is closed). If it's greater than 0 then the label set may change without notice. The application should repeat this call periodically (with interval of 10 seconds to few minutes) and check if the version number has changed. If the version number is greater than earlier then the application should update it's GUI. nvalues field tells how many possible routings are available in the current routing set. The minimum value is 1 which means the routing is fixed. strindex[0..nvalues-1] array contains the indexes to the strings. strings field contains the actual labels. The strindex array gives the pointers into the right label. To get the label for a given label number (0..N) the application can index the strings field in the following way: namelist.strings[namelist.strindex[n]].
The label length should usually be at most 8 characters. However this is not always possible. The application should be able to show at least 8 character positions. If the label is too long it's better to remove some characters from the middle rather than from the end because the last positions usually contain a running number.
There are absolutely no predefined routing names. The name set is fully dynamic and in some cases the ene duser may change it on fly. The names are intended to be human readable. Even it may look like devices have common names like "mic" or "line" this is not the case. Applications assuming this will fail in situations where they get changed to something like "guitar1" or "organs". So the application must present the names to the end user and ask him/her to select among them.
Traditionally many audio applications have used the mixer ioctl calls to change the recording source. This must be avoided because in practice no program does this correctly. In addition the only correct way doesn't work with the freeware OSS clones anyway.
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.
| ossplay.c | Sources for the ossplay audio player and for the ossrecord |
| recsrc.c | A sample program for recording source selection |