More or less looking for comments on the following:

===

I would like to able to deal with 4 chans in a sound driver
that I am writing, and would like to be able to deal with
it through only one attachment to the audio layer.

===

Would anyone object to changing the standard behaviour
of AUDIO_MIXER_DEVINFO from:  (audio(4))

             This command is used iteratively to fetch audio mixer device in-
             formation into the input/output mixer_devinfo_t argument.  To
             query all the supported encodings, start with an index field of
             zero and continue with successive encodings (1, 2, ...) until the
             command returns an error.

to something along the lines of:  the error returned will be ENXIO iff the 
device info is exhausted, and ENODEV if the info in question is not supported
on this card, but there are further fields.
?

This would make it possible to use the same function in the audio driver
to deal with different types of mixer chips.

(i.e. mixer1 supports mutes, but mixer2 does not.  So if a mixer2 is
present the mutes all return ENODEV, so the application continues to
search and still finds things that are supported later.)

I was thinking that one could just put the mutes at the end, but from
audio(4) --

     By convention, all the mixer device indices for generic class grouping
     are at the end of the index number space for a particular hardware de-
     vice, and can be distinguished from other mixer controls because they use
     a name from one of the AudioC* string values.

I suppose that it would also be valid to change that to classes appear
at the beginning.

===

Would be it be too much cruft to change dev/mulaw.c to enable conversion
to/from all of 8/16 bit linear, and mulaw, by making 

void
convert(hdl, e1, e2, p, cc)

which would convert from e1 to e2?  This might be useful.. Esp for
applications that expect certain functionality (e.g. doom.  it wants
16bit linear, doesn't it?)

--
/* Roland C Dowdeswell
 * http://www.imrryr.org/
 */