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

From: Joachim Kuebart <kuebart@mathematik.uni-ulm.de>
To: Frederick Bruckman <fredb@immanent.net>
Cc: Joachim Kuebart <kuebart@mathematik.uni-ulm.de>,
	gnats-bugs@netbsd.org
Subject: Re: kern/29178: confusing behaviour because mixer classes in eap driver are misnamed
Date: Sat, 12 Feb 2005 20:51:56 +0100

 On Fri, Feb 11, 2005 at 06:29:59PM -0600, Frederick Bruckman wrote:
 > In article <20050131230001.6D9E863B849@narn.netbsd.org>,
 > 
 > ...but it sounds like yours, at least, goes like this:
 > 
 > 
 >                 B OUTPUT
 > 		 /
 > 	INPUT-A-+
 > 		 \
 >                 C 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.)
 
 I do agree that the appropriate class for the volume controls at A in the
 picture above is definitely "inputs." The part of my patch that puts these
 in the "record" class should be ignored and I will supply a new patch without
 it upon request or when the remaining issues are resolved (whichever occurs
 first :-).
 
 As far as I can see, there are three naming possibilities for selector B:
 (Since it selects among DAC, Line-In, CD etc., "outputs.select" is clearly
 wrong since that chooses among speaker, headphone and line out).
 
     "outputs.source"
 
 	Under this name, all controls (mic, cd, line, fmsynth, aux and dac)
 	would make sense. The only downside to this name I can think of is
 	that I don't see it mentioned anywhere, so it doesn't seem to be
 	widely used. Maybe other hardware doesn't have this kind of
 	output-source selection.
 
     "monitor.monitor"
 
 	To me this seems like an appropriate name as the selector controls
 	which inputs are played-through, irrespective of whether they are
 	being recorded or not. That is, the inputs selected here can be
 	"monitored" prior to starting a recording. The downside to this
 	suggestion is that in order to hear DAC output, it has to be
 	"monitored." But with a sane initial setting (currently: all on),
 	most software would probably "just work."
 
     "inputs.source"
 
 	This is a good place to put the mic, cd, line and aux controls.
 	Also, it fits well because the volume controls are called inputs.dac
 	and so on.
 
 	However, this solution is a little assymetric since the volume
 	controls affect both recording as well as playback levels, while the
 	selector only affects playback. Also, the "fmsynth" and "dac"
 	sources seem a little misplaced as they're "card-internal" inputs.
 	On the other hand, there's not really any other place to put them...
 
 	With the current implementation, the record.port value of audio_info
 	in AUDIO_SETINFO value controls this selector and therefore selects
 	which of the mic, line and cd sources are played-through, which is
 	not what I would expect from record.port. I would instead expect it
 	to select the recording source, being selector C "record.source". To
 	fix this, the code in dev/audio.c should to be changed to use
 	"record.source" for the value of record.port.
 
 Maybe someone with more overview of the different sound hardwares available
 can comment on some of these choices. In the meantime, I vote for
 "inputs.source."
 
 > 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. 
 
 I must admit I don't completely follow the use_mixerout/cur_port semantics,
 but that's due to my ignorance of the underlying hardware. However, I'm quite
 sure that the bug is indeed the underlying driver (eap) offering
 "outputs.select" which it doesn't have.
 
 > If you trim your patch to only change the outputs.select to inputs.select,
 > does that still fix your problem with "mikmod"?
 
 Further investigation of libmikmod revealed the problem was this: first,
 AUDIO_GETINFO was used, returning a play.port value of 0 since no "speaker,"
 "headhone" or "line out" controls exist in outputs.select. On the subsequent
 AUDIO_SETINFO, the effect was to set outputs.select to 0 and in particular
 disable DAC playback altogether. As soon as "outputs.select" is renamed to
 anything else (see discussion above), the problem goes away.
 
 > I have an "eap", which however doesn't even have an "outputs.select":
 
 Yours is an AC97 which is quite different from mine (shares almost no code
 in dev/pci/eap.c):
 
 eap0 at pci0 dev 6 function 0: vendor 0x1274 product 0x5000 (rev. 0x00)
 eap0: interrupting at eb164 irq 11
 audio0 at eap0: full duplex, mmap, independent
 midi0 at eap0: AudioPCI MIDI UART
 eap0 at pci0 dev 6 function 0: vendor 0x1274 product 0x5000 (rev. 0x00)
 eap0: interrupting at eb164 irq 11
 audio0 at eap0: full duplex, mmap, independent
 midi0 at eap0: AudioPCI MIDI UART
 
 Sorry for such a long post, am I just confused or is this really such an
 involved topic?
 
 Cheers,
 
 cu Jo
 
 -- 
 La perfection est atteinte non quand il ne reste rien à ajouter, mais quand
 il ne reste rien à enlever.  (Antoine de Saint-Exupéry)