Re: ALC883 recording troubles...

From: Vegard Nossum
Date: Thu Jun 12 2008 - 12:55:50 EST


On Thu, Jun 12, 2008 at 4:23 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> Hmm, then it's all what I can guess right now.
> There might be some vendor-specific settings I don't know of.
>
> To be sure, try the following git tree (master branch), pull on
> 2.6.26:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
>
> This contains the patches for the next kernel, and some of them are
> related with Realtek codecs.

Thanks, I've now tried it, but still it doesn't work.

At least the right model is detected, because this is my laptop:

hda_codec.c:2352: hda_codec: model 'acer' is selected for config
1025:11e (Acer Aspire 5720z)

I also applied this patch for some extra debug output (and teach me a
bit about how registers change in response to alsamixer changes):

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index d2e1093..588b69c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -129,6 +129,7 @@ unsigned int snd_hda_codec_read(struct hda_codec *codec, hda
_nid_t nid,
res = (unsigned int)-1;
mutex_unlock(&codec->bus->cmd_mutex);
snd_hda_power_down(codec);
+ snd_printdd("read verb %08x parm %08x = %d\n", verb, parm, res);
return res;
}

@@ -153,6 +154,7 @@ int snd_hda_codec_write(struct hda_codec *codec, hda_nid_t n
id, int direct,
err = codec->bus->ops.command(codec, nid, direct, verb, parm);
mutex_unlock(&codec->bus->cmd_mutex);
snd_hda_power_down(codec);
+ snd_printdd("write verb %08x parm %08x = %d\n", verb, parm, err);
return err;
}

..and in the log, I have this when modifying the "Capture" control:

hda_codec.c:157: write verb 00000300 parm 0000a01a = 0
hda_codec.c:157: write verb 00000300 parm 0000901a = 0

Now I consulted the HDA specification, and I find this surprising:

Verb 3h (set Amplifier Gain/Mute) has the following payload bits:

15 Set Output Amp
14 Set Input Amp

...but the payloads that I logged (a01a and 901a) would correspond to
bit 15 being set, which is the Output Amp!

Does that seem immediately obvious to you?

I will dig some more. Thanks for the help so far.


Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/