newbie problem with control settings

newbie problem with control settings

[D. Hugh Redelmeier]

[I realize that with a bit of knowledge, I wouldn't have had this
problem.  But I think that my experience suggests how to improve
things for other newbies.  By the time I am no longer a newbie, I
will no longer see the things that confuse newbies.]

I updated my system from Fedora Core 1 to Fedora Core 3.  So I
switched from OSS to Alsa.

I had great difficulty getting the sound system to pass line-in
through.  I was trying to use gnome-volume-control to set things up.
Once I understood what was going on, it was easy.

What confused me?  It turns out that my system's sound chip (C-Media
Electronics Inc CM8738 built into my Asus A7V333 motherboard) has a
couple of switches to change the line-in jack into an output.  They are
called "Line-In As Rear" and "Line-In As Bass".  The way to control
them in gnome-volume-control is to select or deselect "mute" for each
of these controls.  I find this not at all obvious.

	Line-In As Bass
	[ ] Mute

	Line-In As Rear
	[ ] Mute

How would I improve it?  I would make the values of these switches be
an enumerated type.  In UI terms: a set of radio buttons.

    Line-in jack is:

    [*] Line-in
    [ ] bass output
    [ ] rear Left and Right output

(Notice that I've replaced two switches with an enumerated type that
has three values.  What happened to the fourth state?  I have no idea
what it would mean, so I didn't provide a choice for it.)

Although I am complaining about gnome-volume-control (not a part of
Alsa), I am guessing that gnome-volume-control is just displaying
names and choices that it is presented by Alsa.

I must say that some of the controls have odd names.  One that really
surprised me was "IEC958 Copyright" with a choice of mute or not.  (I
do now have an idea what this is about.)

Recommendation: I think that there should be support for controls with
enumerated type values.  Perhaps also boolean controls that could have
a name other than "mute".

PS: here are the control names that I extracted from the driver
source.  gnome-volume-control massaged them somewhat.  Some names are
quite obscure.
    Master Playback Volume
    3D Control - Switch
    PCM Playback Volume
    PCM Playback Switch
    PCM Capture Switch
    Synth Playback Volume
    Synth Playback Switch
    Synth Capture Route
    CD Playback Volume
    CD Playback Switch
    CD Capture Route
    Line Playback Volume
    Line Playback Switch
    Line Capture Route
    Mic Playback Volume
    Mic Playback Switch
    Mic Capture Switch
    PC Speaker Playback Volume
    Aux Playback Volume
    Aux Playback Switch
    Aux Capture Switch
    Mic Boost
    Mic Capture Volume
    Four Channel Mode
    Line-In As Rear
    IEC958 Output Switch
    IEC958 In Valid
    IEC958 Copyright
    IEC958 5V
    IEC958 Loop
    IEC958 In Monitor
    IEC958 Playback Default
    IEC958 Playback Con Mask
    IEC958 Playback PCM Stream
    Line-In As Bass
    IEC958 In Select
    IEC958 In Phase Inverse
    Mic As Center/LFE
    Modem


-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click

Re: newbie problem with control settings

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

At Wed, 23 Mar 2005 02:04:56 -0500 (EST),
D. Hugh Redelmeier wrote:
> 
> What confused me?  It turns out that my system's sound chip (C-Media
> Electronics Inc CM8738 built into my Asus A7V333 motherboard) has a
> couple of switches to change the line-in jack into an output.  They are
> called "Line-In As Rear" and "Line-In As Bass".  The way to control
> them in gnome-volume-control is to select or deselect "mute" for each
> of these controls.  I find this not at all obvious.
> 
> 	Line-In As Bass
> 	[ ] Mute
> 
> 	Line-In As Rear
> 	[ ] Mute
> 
> How would I improve it?  I would make the values of these switches be
> an enumerated type.  In UI terms: a set of radio buttons.
> 
>     Line-in jack is:
> 
>     [*] Line-in
>     [ ] bass output
>     [ ] rear Left and Right output

This sounds nice.  The (untested) patch below changes the handling of
these controls as you proposed.


> I must say that some of the controls have odd names.  One that really
> surprised me was "IEC958 Copyright" with a choice of mute or not.  (I
> do now have an idea what this is about.)

This is a problem of gnome-alsa-mixer.
ALSA provides only boolean "switches".  The mixer translates it as a
mute button wrongly.

> Recommendation: I think that there should be support for controls with
> enumerated type values.  Perhaps also boolean controls that could have
> a name other than "mute".

Again, from the driver viewpoint, it's nothing but an on/off switch.
Changing a simple boolean switch to enum is a bad idea in general,
IMO (except for the "modal" case like above).

> PS: here are the control names that I extracted from the driver
> source.  gnome-volume-control massaged them somewhat.  Some names are
> quite obscure.

I guess you mean "IEC958*" controls.  These can be seen in Windows
driver, too, but only in the advanced section.


Takashi

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

Index: alsa-kernel/pci/cmipci.c
===================================================================
RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/cmipci.c,v
retrieving revision 1.91
diff -u -r1.91 cmipci.c
--- alsa-kernel/pci/cmipci.c	22 Mar 2005 17:58:25 -0000	1.91
+++ alsa-kernel/pci/cmipci.c	23 Mar 2005 18:05:35 -0000
@@ -519,40 +519,50 @@
 }
 
 /* bit operations for dword register */
-static void snd_cmipci_set_bit(cmipci_t *cm, unsigned int cmd, unsigned int flag)
+static int snd_cmipci_set_bit(cmipci_t *cm, unsigned int cmd, unsigned int flag)
 {
-	unsigned int val;
-	val = inl(cm->iobase + cmd);
+	unsigned int val, oval;
+	val = oval = inl(cm->iobase + cmd);
 	val |= flag;
+	if (val == oval)
+		return 0;
 	outl(val, cm->iobase + cmd);
+	return 1;
 }
 
-static void snd_cmipci_clear_bit(cmipci_t *cm, unsigned int cmd, unsigned int flag)
+static int snd_cmipci_clear_bit(cmipci_t *cm, unsigned int cmd, unsigned int flag)
 {
-	unsigned int val;
-	val = inl(cm->iobase + cmd);
+	unsigned int val, oval;
+	val = oval = inl(cm->iobase + cmd);
 	val &= ~flag;
+	if (val == oval)
+		return 0;
 	outl(val, cm->iobase + cmd);
+	return 1;
 }
 
-#if 0 // not used
 /* bit operations for byte register */
-static void snd_cmipci_set_bit_b(cmipci_t *cm, unsigned int cmd, unsigned char flag)
+static int snd_cmipci_set_bit_b(cmipci_t *cm, unsigned int cmd, unsigned char flag)
 {
-	unsigned char val;
-	val = inb(cm->iobase + cmd);
+	unsigned char val, oval;
+	val = oval = inb(cm->iobase + cmd);
 	val |= flag;
+	if (val == oval)
+		return 0;
 	outb(val, cm->iobase + cmd);
+	return 1;
 }
 
-static void snd_cmipci_clear_bit_b(cmipci_t *cm, unsigned int cmd, unsigned char flag)
+static int snd_cmipci_clear_bit_b(cmipci_t *cm, unsigned int cmd, unsigned char flag)
 {
-	unsigned char val;
-	val = inb(cm->iobase + cmd);
+	unsigned char val, oval;
+	val = oval = inb(cm->iobase + cmd);
 	val &= ~flag;
+	if (val == oval)
+		return 0;
 	outb(val, cm->iobase + cmd);
+	return 1;
 }
-#endif
 
 
 /*
@@ -2250,8 +2260,8 @@
 DEFINE_SWITCH_ARG(exchange_dac, CM_REG_MISC_CTRL, CM_XCHGDAC, CM_XCHGDAC, 0, 0);
 #endif
 DEFINE_BIT_SWITCH_ARG(fourch, CM_REG_MISC_CTRL, CM_N4SPK3D, 0, 0);
-DEFINE_BIT_SWITCH_ARG(line_rear, CM_REG_MIXER1, CM_SPK4, 1, 0);
-DEFINE_BIT_SWITCH_ARG(line_bass, CM_REG_LEGACY_CTRL, CM_LINE_AS_BASS, 0, 0);
+// DEFINE_BIT_SWITCH_ARG(line_rear, CM_REG_MIXER1, CM_SPK4, 1, 0);
+// DEFINE_BIT_SWITCH_ARG(line_bass, CM_REG_LEGACY_CTRL, CM_LINE_AS_BASS, 0, 0);
 // DEFINE_BIT_SWITCH_ARG(joystick, CM_REG_FUNCTRL1, CM_JYSTK_EN, 0, 0); /* now module option */
 DEFINE_SWITCH_ARG(modem, CM_REG_MISC_CTRL, CM_FLINKON|CM_FLINKOFF, CM_FLINKON, 0, 0);
 
@@ -2300,10 +2310,114 @@
 }
 
 
+static int snd_cmipci_line_in_mode_info(snd_kcontrol_t *kcontrol,
+					snd_ctl_elem_info_t *uinfo)
+{
+	cmipci_t *cm = snd_kcontrol_chip(kcontrol);
+	static char *texts[3] = { "Line-In", "Rear Output", "Bass Output" };
+	uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
+	uinfo->count = 1;
+	uinfo->value.enumerated.items = cm->chip_version >= 39 ? 3 : 2;
+	if (uinfo->value.enumerated.item >= uinfo->value.enumerated.items)
+		uinfo->value.enumerated.item = uinfo->value.enumerated.items - 1;
+	strcpy(uinfo->value.enumerated.name, texts[uinfo->value.enumerated.item]);
+	return 0;
+}
+
+static inline unsigned int get_line_in_mode(cmipci_t *cm)
+{
+	unsigned int val;
+	if (cm->chip_version >= 39) {
+		val = snd_cmipci_read(cm, CM_REG_LEGACY_CTRL);
+		if (val & CM_LINE_AS_BASS)
+			return 2;
+	}
+	val = snd_cmipci_read_b(cm, CM_REG_MIXER1);
+	if (val & CM_SPK4)
+		return 1;
+	return 0;
+}
+
+static int snd_cmipci_line_in_mode_get(snd_kcontrol_t *kcontrol,
+				       snd_ctl_elem_value_t *ucontrol)
+{
+	cmipci_t *cm = snd_kcontrol_chip(kcontrol);
+
+	spin_lock_irq(&cm->reg_lock);
+	ucontrol->value.enumerated.item[0] = get_line_in_mode(cm);
+	spin_unlock_irq(&cm->reg_lock);
+	return 0;
+}
+
+static int snd_cmipci_line_in_mode_put(snd_kcontrol_t *kcontrol,
+				       snd_ctl_elem_value_t *ucontrol)
+{
+	cmipci_t *cm = snd_kcontrol_chip(kcontrol);
+	int change;
+
+	spin_lock_irq(&cm->reg_lock);
+	if (ucontrol->value.enumerated.item[0] == 2)
+		change = snd_cmipci_set_bit(cm, CM_REG_LEGACY_CTRL, CM_LINE_AS_BASS);
+	else
+		change = snd_cmipci_clear_bit(cm, CM_REG_LEGACY_CTRL, CM_LINE_AS_BASS);
+	if (ucontrol->value.enumerated.item[0] == 1)
+		change |= snd_cmipci_set_bit_b(cm, CM_REG_MIXER1, CM_SPK4);
+	else
+		change |= snd_cmipci_clear_bit_b(cm, CM_REG_MIXER1, CM_SPK4);
+	spin_unlock_irq(&cm->reg_lock);
+	return change;
+}
+
+static int snd_cmipci_mic_in_mode_info(snd_kcontrol_t *kcontrol,
+				       snd_ctl_elem_info_t *uinfo)
+{
+	static char *texts[2] = { "Mic-In", "Center/LFE Output" };
+	uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
+	uinfo->count = 1;
+	uinfo->value.enumerated.items = 2;
+	if (uinfo->value.enumerated.item >= uinfo->value.enumerated.items)
+		uinfo->value.enumerated.item = uinfo->value.enumerated.items - 1;
+	strcpy(uinfo->value.enumerated.name, texts[uinfo->value.enumerated.item]);
+	return 0;
+}
+
+static int snd_cmipci_mic_in_mode_get(snd_kcontrol_t *kcontrol,
+				      snd_ctl_elem_value_t *ucontrol)
+{
+	cmipci_t *cm = snd_kcontrol_chip(kcontrol);
+	/* same bit as spdi_phase */
+	spin_lock_irq(&cm->reg_lock);
+	ucontrol->value.enumerated.item[0] = 
+		(snd_cmipci_read_b(cm, CM_REG_MISC) & CM_SPDIF_INVERSE) ? 1 : 0;
+	spin_unlock_irq(&cm->reg_lock);
+	return 0;
+}
+
+static int snd_cmipci_mic_in_mode_put(snd_kcontrol_t *kcontrol,
+				      snd_ctl_elem_value_t *ucontrol)
+{
+	cmipci_t *cm = snd_kcontrol_chip(kcontrol);
+	int change;
+
+	spin_lock_irq(&cm->reg_lock);
+	if (ucontrol->value.enumerated.item[0])
+		change = snd_cmipci_set_bit_b(cm, CM_REG_MISC, CM_SPDIF_INVERSE);
+	else
+		change = snd_cmipci_clear_bit_b(cm, CM_REG_MISC, CM_SPDIF_INVERSE);
+	spin_unlock_irq(&cm->reg_lock);
+	return change;
+}
+
 /* both for CM8338/8738 */
 static snd_kcontrol_new_t snd_cmipci_mixer_switches[] __devinitdata = {
 	DEFINE_MIXER_SWITCH("Four Channel Mode", fourch),
-	DEFINE_MIXER_SWITCH("Line-In As Rear", line_rear),
+	{
+		.name = "Line-In Mode",
+		.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+		.info = snd_cmipci_line_in_mode_info,
+		.get = snd_cmipci_line_in_mode_get,
+		.put = snd_cmipci_line_in_mode_put,
+	},
 };
 
 /* for non-multichannel chips */
@@ -2341,10 +2455,15 @@
 
 /* only for model 039 or later */
 static snd_kcontrol_new_t snd_cmipci_extra_mixer_switches[] __devinitdata = {
-	DEFINE_MIXER_SWITCH("Line-In As Bass", line_bass),
 	DEFINE_MIXER_SWITCH("IEC958 In Select", spdif_in_sel2),
 	DEFINE_MIXER_SWITCH("IEC958 In Phase Inverse", spdi_phase2),
-	DEFINE_MIXER_SWITCH("Mic As Center/LFE", spdi_phase), /* same bit as spdi_phase */
+	{
+		.name = "Mic-In Mode",
+		.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+		.info = snd_cmipci_mic_in_mode_info,
+		.get = snd_cmipci_mic_in_mode_get,
+		.put = snd_cmipci_mic_in_mode_put,
+	}
 };
 
 /* card control switches */

Re: newbie problem with control settings

[Clemens Ladisch]

D. Hugh Redelmeier wrote:
> I must say that some of the controls have odd names.  One that really
> surprised me was "IEC958 Copyright" with a choice of mute or not.  (I
> do now have an idea what this is about.)

"IEC958" is S/P-DIF.  This control enables the copyright bit which can
cause receiving devices to disable digital recording.

> Recommendation: I think that there should be support for controls with
> enumerated type values.

The support is there, but these controls are implemented as booleans
in the hardware.

An additional mixer API that can map these controls to more
user-friendly ones is being planned.

> Perhaps also boolean controls that could have a name other than
> "mute".

These controls aren't named "Mute"; this is a gnome-volume-control
bug.


HTH
Clemens



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: newbie problem with control settings

[Lee Revell]

On Thu, 2005-03-24 at 11:06 +0100, Clemens Ladisch wrote:
> > Perhaps also boolean controls that could have a name other than
> > "mute".
> 
> These controls aren't named "Mute"; this is a gnome-volume-control
> bug.

FWIW, I just installed Gnome 2.10 on one of my machines and the mixer is
*drastically* better.  The views are split into Playback and Capture,
the widgets are much cleaner looking, and most of the "advanced"
controls are hidden by default.

Many of the bug reports about incomprehensible mixer, especially for the
emu10k1, will be resolved when users switch.

Lee



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click

Re: newbie problem with control settings

[Takashi Iwai]

At Wed, 23 Mar 2005 19:07:28 +0100,
I wrote:
> 
> > How would I improve it?  I would make the values of these switches be
> > an enumerated type.  In UI terms: a set of radio buttons.
> > 
> >     Line-in jack is:
> > 
> >     [*] Line-in
> >     [ ] bass output
> >     [ ] rear Left and Right output
> 
> This sounds nice.  The (untested) patch below changes the handling of
> these controls as you proposed.

Can any one test the patch?


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: newbie problem with control settings

[D. Hugh Redelmeier]

| From: Takashi Iwai <tiwai@suse.de>

| > >     Line-in jack is:
| > > 
| > >     [*] Line-in
| > >     [ ] bass output
| > >     [ ] rear Left and Right output
| > 
| > This sounds nice.  The (untested) patch below changes the handling of
| > these controls as you proposed.
| 
| Can any one test the patch?

Thanks very much for this patch.  Unfortunately I am unable to test
it.

I do have a question about the patch.  How is a mixer supposed to find
out the names of the three possible values?  I see that there is a new
control named "Mic-In Mode" but I don't see where the possible
settings are described.


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30

Re: newbie problem with control settings

[Takashi Iwai]

At Thu, 31 Mar 2005 14:07:17 -0500 (EST),
D. Hugh Redelmeier wrote:
> 
> | From: Takashi Iwai <tiwai@suse.de>
> 
> | > >     Line-in jack is:
> | > > 
> | > >     [*] Line-in
> | > >     [ ] bass output
> | > >     [ ] rear Left and Right output
> | > 
> | > This sounds nice.  The (untested) patch below changes the handling of
> | > these controls as you proposed.
> | 
> | Can any one test the patch?
> 
> Thanks very much for this patch.  Unfortunately I am unable to test
> it.
> 
> I do have a question about the patch.  How is a mixer supposed to find
> out the names of the three possible values?  I see that there is a new
> control named "Mic-In Mode" but I don't see where the possible
> settings are described.

"Line-In Mode" and "Mic-In Mode" are enum controls.
You can find their items in their info callbacks.
The former has "Line-In", "Rear Output" and "Bass Output", while the
latter has "Mic-In" and "Center/LFE Output".


Takashi


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30