[alsa-devel] ATI Technologies Inc SBx00 Azalia

[Takashi Iwai]

At Fri, 11 Jan 2008 17:11:56 +0100,
Markus Rechberger wrote:
> 
> Hi Takashi,
> 
> On Jan 11, 2008 4:15 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > At Fri, 11 Jan 2008 15:47:56 +0100,
> > Markus Rechberger wrote:
> > >
> > > Hi,
> > >
> > > there seems to be an issue with this ATI SBx00 Azalia driver.
> >
> > It's rather about the codec than the controller.
> >
> > > nmixer (which uses the oss emulated interface shows up 4 controls)
> > > Vol (volume which seems to control the whole output volume)
> > > PCM2 (maybe not routed on that notebook, it practically has no effect)
> > > IGain (guess for the microphone which I haven't tested yet)
> > > Digital1 (don't know)
> > >
> > > if I try to start alsamixer, it doesn't seem to work and I get an
> > > entry in dmesg whenever I try to run it:
> > > $ alsamixer
> > > alsamixer: function snd_mixer_load failed: Invalid argument
> > >
> > > $ dmesg
> > > ...
> > > [ 1269.997724] hda_codec: num_steps = 0 for NID=0x12
> >
> > Looks like the invalid access to HD-audio codec occurs.
> > Since it's an unknown device, the driver tries to probe the BIOS
> > setting.  Maybe there is some bug there.
> >
> > Anyway, try the latest ALSA HG version if you still didn't.  There
> > are some recent fixes regarding the realtek auto-probe routine.
> >
> 
> I'm using the latest one.
> 
> > Also, use the patch below.  This will show which control element is
> > affected.
> >
> 
> [   39.753443] hda_codec: Unknown model for ALC262, trying auto-probe
> from BIOS...
> [   39.754025] ALSA /devel/alsa/alsa-driver/pci/hda/hda_codec.c:2855:
> autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0)
> [   39.754029] ALSA /devel/alsa/alsa-driver/pci/hda/hda_codec.c:2859:
>   speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> [   39.754032] ALSA /devel/alsa/alsa-driver/pci/hda/hda_codec.c:2863:
>   hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> [   39.754035] ALSA /devel/alsa/alsa-driver/pci/hda/hda_codec.c:2871:
>   inputs: mic=0x12, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0
> [   39.828608] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)
> [   40.497040] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)
> [   40.500522] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)
> [   40.504570] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)
> [   40.508863] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)
> [   40.513168] hda_codec: num_steps = 0 for NID=0x12 (ctl = Mic Boost)

Ah, so your machine uses the digital-mic for the mic input.  That's
new.

Does the patch below fix the problem?


Takashi

diff -r 80b452643ca6 pci/hda/patch_realtek.c
--- a/pci/hda/patch_realtek.c	Fri Jan 11 16:12:23 2008 +0100
+++ b/pci/hda/patch_realtek.c	Fri Jan 11 17:19:27 2008 +0100
@@ -6111,7 +6111,7 @@ static int alc_auto_add_mic_boost(struct
 	hda_nid_t nid;
 
 	nid = spec->autocfg.input_pins[AUTO_PIN_MIC];
-	if (nid) {
+	if (nid && (get_wcaps(codec, nid) & AC_WCAP_IN_AMP)) {
 		err = add_control(spec, ALC_CTL_WIDGET_VOL,
 				  "Mic Boost",
 				  HDA_COMPOSE_AMP_VAL(nid, 3, 0, HDA_INPUT));
@@ -6119,7 +6119,7 @@ static int alc_auto_add_mic_boost(struct
 			return err;
 	}
 	nid = spec->autocfg.input_pins[AUTO_PIN_FRONT_MIC];
-	if (nid) {
+	if (nid && (get_wcaps(codec, nid) & AC_WCAP_IN_AMP)) {
 		err = add_control(spec, ALC_CTL_WIDGET_VOL,
 				  "Front Mic Boost",
 				  HDA_COMPOSE_AMP_VAL(nid, 3, 0, HDA_INPUT));