>Date: Fri, 04 Aug 1995 18:26:05 -0400
>From: John Brezak <brezak@apollo.hp.com>

>The strings are there for the use by audio independent mixer apps. The intent
>was to allow the app to get all of the information from the system as to
>the audio paths and controls.
>
>What could be done is to use id's for well known devices and reserve a value
>for "custom". The custom value will have a string name supplied by the driver.

That sounds reasonable.  Now all we need to do is decide which devices
(encodings, etc.) are "well known."  :-/

Sun's audio_prinfo_t includes a bitfield called 'avail_ports'.  They
define the symbols AUDIO_SPEAKER, AUDIO_HEADPHONE, and AUDIO_LINE_OUT
for output ports; and AUDIO_MICROPHONE and AUDIO_LINE_IN for input
ports.  We could do something similar, and add something like
AUDIO_OTHER so that apps can use another ioctl to get string(s).

I've looked at the NAS (network audio system; see
ftp://ftp.x.org/contrib/audio/nas/) and it looks like the audio system
in Solaris works slightly differently from the one in SunOS 4.1.  I
don't have access to any Solaris boxes, so I'd appreciate it if
someone who does could send me some info (especially Solaris' audio.4
and audioio.h).

I hope people don't think I'm obsessed with Sun compatibility; but I
think that compatibility will save us grief later.  Also, the time to
nail all this stuff down is now, before someone writes another audio
app for which they won't provide sources (like vat).
-- 
Mike Long <mike.long@analog.com>           http://www.shore.net/~mikel
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA                assert(*this!=opinionof(Analog));