Is there a convention for mapping codec vendor's register::bit names to alsa control names?

Is there a convention for mapping codec vendor's register::bit names to alsa control names?

[John Utz]

[-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --]

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),
/* 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),
  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

*and* one set the existing "Alternate Level to Surround Out" to 0


This is super-duper non obvious in alsamixer.

Hell, i'd just *coded* the damn thing and i had to poke alsamixer a few times to get it right.


So, what's the convention on things like this?

As a developer, i'd prefer that things match the chip docs so i can figure out what's going on in the code (thus my previous on-list gripes about register naming macros not matching the AC97 standard).

As a user, i'd prefer that it be easy to figure out what the hell i am supposed to do to get the hardware to do what i want?


What to do?

tnx!

johnu

As a user, i'd prefer that thing



However,


[-- Attachment #1.2: Type: text/html, Size: 2519 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Is there a convention for mapping codec vendor's register::bit names to alsa control names?

[Takashi Iwai]

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).

> /* 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).

>   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?
If no, we can hardcode these bits in the initialization sequence.

> *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.

(Actually, such an abstraction could be implemented in alsa-lib side,
 I come to believe that the simplification in the driver is much
 easier.)


thanks,

Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Is there a convention for mapping codec vendor's register::bit names to alsa control names?

[John Utz]

[-- Attachment #1.1: Type: text/plain, Size: 5349 bytes --]

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



[-- Attachment #1.2: Type: text/html, Size: 7762 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Is there a convention for mapping codec vendor's register::bit names to alsa control names?

[Takashi Iwai]

At Thu, 22 Feb 2007 10:04:20 -0800,
John Utz wrote:
> 
> * 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.

Well, too minimized to understand quite what they mean :)
Could you explain a bit more detail?


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Is there a convention for mapping codec vendor's register::bit names to alsa control names?

[John Utz]

[-- Attachment #1.1: Type: text/plain, Size: 3427 bytes --]

PLz forgive if you see this twice, outlook web access is tormenting me further


-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de]
Sent: Fri 2/23/2007 7:19 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 Thu, 22 Feb 2007 10:04:20 -0800,
John Utz wrote:
> 
> * 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.

* Well, too minimized to understand quite what they mean :)
* Could you explain a bit more detail?


yes, certainly! this matrix is called 'Mixer Table'


The bit's are as follows, complete with documentation mistakes :


SM51 is a mistake, it's listed in the docs as SM51EN. it has a 1 line decription:

  'Smart 5.1 feature (See Mixer Table)'


SM51SW is corrent, it has a 1 line description:

  'Smart 5.1 feature (See Mixer Table)'


SMIC is a mistake, it's listed in the docs as MS, it has a 1 line description:

  'Microphone Select (See Table Below)'


20XL i have NO IDEA what this is.

20XR i have NO IDEA what this is.


MIC{1,2,3} i ASSUME are routing for different mic inputs


L{L,R} i am pretty sure is Line In Left and Right

S{L,R} is Surround Left and Right

CEN and LFE are Center and Low Frequency Enhancement


These are the different choices in the matrix, i dont like the idea of arbitrarily picking a setup that turns on surround and ignores the other choices.

My current code surfaces all 3 bits:

  AC97_SINGLE("Smart 5.1 Control A", 0x20,  8, 1, 0),
  AC97_SINGLE("Smart 5.1 Control B", 0x7a, 15, 1, 0),
  AC97_SINGLE("Smart 5.1 Control C", 0x7a, 14, 1, 0)

I havent come up with any better idea.

tnx for any thoughts you may have.


johnu

* Takashi



[-- Attachment #1.2: Type: text/html, Size: 5601 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel