With the impending EOF of sdtaudiocontrol (LSARC 2009/074, times out
2/16/2009), I believe that there are no further applications which exist
and make use of most of the ioctls spelled out in mixer(7i).
Specifically, the following ioctls are in question:
AUDIO_MIXERCTL_GET_MODE
AUDIO_MIXERCTL_SET_MODE
AUDIO_MIXERCTL_GET_CHINFO
AUDIO_MIXERCTL_SET_CHINFO
AUDIO_MIXERCTL_GETINFO
AUDIO_MIXERCTL_SETINFO
AUDIO_MIXER_MULTIPLE_OPEN*
AUDIO_MIXER_SINGLE_OPEN
additionally, the following ioctls in audio_support(7i) don't appear to
be used by any other applications either:
AUDIO_GET_NUM_CHS
AUDIO_GET_CH_NUMBER
AUDIO_GET_CH_TYPE
* (AUDIO_MIXER_MULTIPLE_OPEN is called by some 3rd party code, but none
of the code I've seen, including gstreamer, actually *relies* on it.
All the code I've seen simply ignores the result code.)
I'd like to eliminate these ioctls from the Boomer code base. There is
a huge amount of complexity that these ioctls create, due largely to the
poorly thought out way in which the mixer API was tacked onto the main
audio API, as well as ambiguity in what some of them do. Furthermore,
no applications that wanted to be reasonably portable could rely on
them, since historically not all audio devices have supported the mixer
API. (Sun Ray still doesn't support this API.)
Such a clean up would eliminate many hundreds of lines of complex code,
including the need for some rather Byzantine locking and synchronization
that has to be done between streams.
Note that I'm not proposing to eliminate the ability of multiple
applications to use the audio device simultaneously. What instead I'm
proposing to do is treat each process as if it had its own private
device; that means that only one audio file (or two if one is read and
the other is write) can be open at a time.
Applications that want to do more sophisticated things with audio should
really consider the OSS API. The OSS API is much saner in significant
ways, and is free from the worst of the synchronization problems and
ambiguity that plagues the mixer(7i) and audio(7i) APIs. (Plus, in
Boomer, you have a lot more flexibility with other things.)
If anyone has any significant objections to this, I'd like to hear
them. Likewise if anyone knows any applications other than
sdtaudiocontrol and mixerctl which use the above APIs, I'd like to
know. (And yes, we'll be "fixing" mixerctl to not use the APIs in
question as part of Boomer.)
-- Garrett
