Subject: kern/8479: ossaudio emulation (mis-)interprets record source MIXER_ENUMs
To: None <firstname.lastname@example.org>
From: Klaus Klein <email@example.com>
Date: 09/23/1999 05:36:47
>Synopsis: ossaudio emulation (mis-)interprets record source MIXER_ENUMs
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Thu Sep 23 05:35:01 1999
>Originator: Klaus Klein
Frobozz Magic Standards Company
>Release: any to this date
System: NetBSD minor-variation 1.4K NetBSD 1.4K (MINOR-VARIATION) #254: Thu Sep 16 22:05:52 CEST 1999 kleink@minor-variation:/vol/tmp/kernels/MINOR-VARIATION i386
The ossaudio emulation interprets the (opaque) value of an
enumerated record source selector's ord member as the index of
the corresponding MIXER_VALUE. This method breaks whenever a
hardware driver chooses to use the enumeration to conveniently
hold i.e. the corresponding values for its record source
selector hardware register.
Worse, a hardware driver may provide support for record sources
which do not even have a corresponding MIXER_VALUE, i.e. the
record mixer output itself, so making this a general API
requirement isn't possible either.
(The MIXER_SET code makes a similar assumption.)
A secondary problem caused by this is that the emulation depends on
the record source selector being assigned a mixer device index
greater than that of any `ord'-style record source; otherwise,
the reverse mapping for that index will be uninitialized.
When using the eso(4) hardware driver:
1) Set mixerctl -w record.source=cd (corresponding ord = 2)
2) Start i.e. xxmix; be suprprised to find its record source
selector indicating `line' (= 2 = ESO_LINE_PLAY_VOL) while
mixerctl (and the hardware) still indicates cd.
After MIXER_VALUEs are determined, add a level of indirection
to look for the relevant bits?