linux-kernel - Re: ALC883 recording troubles...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19f34abd0806120955r4734bca8h44774bacc65aca37@mail.gmail.com>
Date:	Thu, 12 Jun 2008 18:55:40 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Takashi Iwai" <tiwai@...e.de>
Cc:	"Daniel J Blueman" <daniel.blueman@...il.com>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: ALC883 recording troubles...

On Thu, Jun 12, 2008 at 4:23 PM, Takashi Iwai <tiwai@...e.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/