I have to escape from the non standards compliant hell of Outlook Web Access. :-( I have no way of correctly citing other than typing all the characters in myself, that's too lame. So plz forgive my quasi-cite :-) -----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thu 2/22/2007 3:02 AM To: John Utz Cc: alsa-devel@lists.sourceforge.net Subject: Re: [Alsa-devel] Is there a convention for mapping codec vendor's register::bit names to alsa control names? At Wed, 21 Feb 2007 14:11:11 -0800, John Utz wrote: > > I have some improvements to the VIA 1617a support submitted a few weeks ago by daniel > jacobowitz (they are in 1.0.14rc2). > > I have added 4 new controls, 3 of which are required to support enabling VIA's > 'Smart51' for the 1617a: > > static const struct snd_kcontrol_new snd_ac97_controls_vt1617a[] = { > AC97_SINGLE("Center/LFE Exch", 0x5a, 8, 1, 0), * You don't have to shorten the word. The mixer element has a long * enough space (up to 43 letters). Okay > /* these bits form a matrix that allows for the limited configuration of > * outputs and inputs to enable surround sound input > AC97_SINGLE("Microphone Select", 0x20, 8, 1, 0), * An enum type control would be suitable for this kind of controls (if * really needed). what would the enum look like? > AC97_SINGLE("Smart 5.1 Switch", 0x7a, 15, 1, 0), > AC97_SINGLE("Smart 5.1 Enable", 0x7a, 14, 1, 0) > }; > > These are the names that Uncle Via's hard working engineers have assigned to these > bits in their released documentation but surfacing these names in the ui looks to me > to be a usability nightmare :-( > > To wit; enabling surround sound on a board that only has 3 jacks requires setting > > "Microphone Select" to 0 > "Smart 5.1 Switch" to 1 > "Smart 5.1 Enable" to 1 * Is there any case that you need to turn off these bits? yes! on any system that has specific surround outputs in addition to the mic and line in then this would probably be a bad idea. * If no, we can hardcode these bits in the initialization sequence. these bits form a matrix that configure some combinations of mic ins, line ins and surround outputs. In the case of somebody that has a full collection of plugins/plugouts, their surround output might not work as expected. And, that person might want to sometimes change the line in and the speaker out to be more mic inputs. So surfacing flexibility to the end user is important. The problem with surfacing this is that matrix is pretty hard to follow: 1. the doc has some bugs; ie SM51 and SMIC are not the names of the bits 2. the collection of choices is so strange that it looks like the result of running a gate minimization program instead of choosing the matrix based on user need :-) Controller Bit MICIN I/O SM51 SM51SW SMIC 20XL 20XR MIC1 MIC2 MIC3 LL LR 0 0 0 MIC1 MIC1 MIC1 - - LL LR 0 0 1 MIC1 MIC3 MIC1 - MIC3 LL LR 0 1 0 MIC2 MIC2 - MIC2 - LL LR 0 1 1 MIC1 MIC2 MIC1 MIC2 - LL LR 1 0 0 MIC3 MIC3 CEN LFE MIC3 SURL SURR 1 0 1 MIC3 MIC3 CENT LFE MIC3 LL LR 1 1 0 MIC1 MIC1 Mic1 LFE SURL SURR 1 1 1 MIC1 MIC2 MIC1 MIC2- LFE SURL SURR If somebody can make sense of this by assigning a simple meaning to each input bit in this karnaugh map then i'd welcome that insight! However, having looked at this for several hours, I think this is already minimized. > *and* one set the existing "Alternate Level to Surround Out" to 0 > > This is super-duper non obvious in alsamixer. * Strongly agree. * * Alternatively, if we really need a mixer switch to toggle these bits, * create combinient one such as "Surround Output Switch", which * enables/disables all these bits together as a single control. I that it might be possible to do this correctly, but i think that the correct solution space is very small and the 'Works out of the Box for Some Folks, Absolutely Infuriates Everybody Else' solution space is much, much larger. :-( *(Actually, such an abstraction could be implemented in alsa-lib side, * I come to believe that the simplification in the driver is much * easier.) This statement parses ambiguously; are you saying that you would prefer to see control aggregation should occur in the driver or the lib? You have been at this code for a very long time and the fact that you have come to a conclusion as a result of your substantive experience gives your conclusion very great weight. Having said that :-), IMHO, control aggregation should occur in the library and the not in the driver. Driver is for bitflipping only; exports ioctls (or in the case of my beloved freebsd; sysctls). Lib is for configuring bits for setting up surround and whatnot. Lib Plugin is for Data Manipulation; resamp, eq, channel split, etc - yes, i know this is also a hardware function too, it's an imperfect world :-) Currently, the driver is quite a motley mix of things because hard working contributors have made things work as best they could. tnx! johnu * thanks, * * Takashi