The following reply was made to PR kern/29178; it has been noted by GNATS.

From: fredb@immanent.net (Frederick Bruckman)
To: Joachim Kuebart <kuebart@mathematik.uni-ulm.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/29178: confusing behaviour because mixer classes in eap driver are misnamed
Date: Fri, 11 Feb 2005 18:29:59 -0600 (CST)

 In article <20050131230001.6D9E863B849@narn.netbsd.org>,
 	Joachim Kuebart <kuebart@mathematik.uni-ulm.de> writes:
 
 > 	There are two problems with this: firstly, a study of
 > 	<ftp://ftp.alsa-project.org/pub/manuals/asahi_kasei/4531.pdf> reveals
 > 	that the mixers addressed by the inputs.* volume settings actually
 > 	affect both the play-through as well as the recording volume. This
 > 	means that they should be in the record.* class rather than the
 > 	inputs.* class according to my understanding of the following section
 > 	of audio(9):
 > 
 > 		Each of the named sources for which the recording level can
 > 		be set should have a control in the AudioCrecord class of
 > 		type AUDIO_MIXER_VALUE...
 > 
 > 		Controls for various sources that affect only the playback
 > 		output, as opposed to recording, should be in the
 > 		AudioCinputs class.
 
 I wrote that text, but I'm not so sure now it make sense. I thought all
 the underlying hardware would like this this:
 
 
         INPUT \
                 OUTPUT
         RECORD /
 
 
 ...but it sounds like yours, at least, goes like this:
 
 
                  OUTPUT
 		/
 	INPUT--+
 		\
                  RECORD
 
 
 If that's the case, "input" seems like a a better name for a mixer node
 that controls *both* playback and record, doesn't it?  (If you agree, I
 could change that man page.)
 
 > 	Note that the AK4531 does not have any volume controls that affect
 > 	only playback (except for outputs.master, obviously).
 > 
 > 	Secondly, the outputs.select control is apparently wrong as it is
 > 	supposed to refer to output destinations, cf. again audio(9):
 > 
 > 		If the play mixer is capable of output to more than one
 > 		destination, it should define AudioNselect in class
 > 		AudioCoutputs. This mixer control should be of type
 > 		AUDIO_MIXER_ENUM or AUDIO_MIXER_SET and enumerate the
 > 		possible destinations.
 > 
 > 	Instead, the channel names in the above example as well as the
 > 	circuitry inside the AK4531 show that these controls actually control
 > 	which inputs are switched through to the output mixer. The sentence
 > 
 > 		...various sources in class AudioCrecord will be combined and
 > 		presented to the single recording output, in the same fashion
 > 		that the sources of class AudioCinputs are combined and
 > 		presented to the playback output(s).
 > 
 > 	in audio(9) suggests that this is what the inputs.select control is
 > 	supposed to do.
 
 Yes, I agree completely. (I wrote that text, too.)
 
 > 	Note again that the AK4531 has only one output and thus does not
 > 	offer the functionality described for outputs.select.
 
 The idea behind my last change to the audio layer, was for the volume
 setter to prefer the mixer and the detail control if available, else to
 go with the master. I didn't get to test with anything that had an
 "output.select", so I guessed as best I could. It sounds like this is
 a bug in the underlying driver, though. 
 
 > 	The described problem appears to be one of nomenclature at first
 > 	sight, but it actually has a greater effect on how the "port" value
 > 	in AUDIO_SET and AUDIO_GET ioctls is treated. With the current
 > 	implementation, one has the problem that an audio program that
 > 	selects "speaker" output (as, for example, libmikmod) will instead
 > 	deactivate output alltogether because the outputs.select control gets
 > 	set to zero for want of a mixer labelled "speaker" on the AK4531.
 > 	This is clearly not the intended behaviour.
 
 If you trim your patch to only change the outputs.select to inputs.select,
 does that still fix your problem with "mikmod"?
 
 I have an "eap", which however doesn't even have an "outputs.select":
 
 	# grep eap /var/run/dmesg.boot 
 	eap0 at pci4 dev 6 function 0: Ensoniq AudioPCI 97 ES1371-B (rev. 0x09)
 	eap0: interrupting at ioapic0 pin 20 (irq 5)
 	eap0: ac97: Crystal CS4297A codec; headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D
 	eap0: ac97: ext id 200<AMAP>
 	audio0 at eap0: full duplex, mmap, independent
 	midi0 at eap0: AudioPCI MIDI UART
 	# mixerctl -a | grep outputs  
 	outputs.master=119,119
 	outputs.master.mute=off
 	outputs.mono=255
 	outputs.mono.mute=on
 	outputs.mono.source=mixerout
 	outputs.headphones=255,255
 	outputs.headphones.mute=off
 	outputs.spatial=on
 	outputs.spatial.center=0
 	outputs.spatial.depth=96
 
 I suppose many don't, so that one change should be "safe".
 
 Kind regards,
 
 
 Frederick