>Number:         8479
>Category:       kern
>Synopsis:       ossaudio emulation (mis-)interprets record source MIXER_ENUMs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 23 05:35:01 1999
>Last-Modified:
>Originator:     Klaus Klein
>Organization:
Frobozz Magic Standards Company
>Release:        any to this date
>Environment:
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


>Description:
	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.

>How-To-Repeat:
	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.

>Fix:
	After MIXER_VALUEs are determined, add a level of indirection
	to look for the relevant bits?
>Audit-Trail:
>Unformatted: