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: <s5h3ani1qvs.wl%tiwai@suse.de>
Date:	Thu, 12 Jun 2008 19:53:43 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	"Vegard Nossum" <vegard.nossum@...il.com>
Cc:	"Daniel J Blueman" <daniel.blueman@...il.com>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: ALC883 recording troubles...

At Thu, 12 Jun 2008 19:29:57 +0200,
Vegard Nossum wrote:
> 
> On Thu, Jun 12, 2008 at 6:55 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> > 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!
> 
> I applied this as well, just to make sure, and I tested again:
> 
> @@ -906,6 +908,9 @@ int snd_hda_codec_amp_update(struct hda_codec
> *codec, hda_nid_t nid, int ch,
>  {
>         struct hda_amp_info *info;
> 
> +       printk(KERN_ERR "snd_hda_codec_amp_update(): direction = %s\n",
> +               direction == HDA_OUTPUT ? "output" : "input");
> +
>         info = get_alloc_amp_hash(codec, HDA_HASH_KEY(nid, direction, idx));
>         if (!info)
>                 return 0;
> 
> ..and yes, changing the "Capture" level does indeed set the Output bit
> when modifying this control. Maybe there's something wrong with the
> set-up of mixer or pin controls that makes ALSA think this is an
> output stream?
> 
> Is there something strange here:
> 
> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>   Pin Default 0x02a19840: [Jack] Mic at Ext Front
> 
> Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
>   Pin Default 0x99a30941: [Fixed] Mic at Int ATAPI
> 
> Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>   Pin Default 0x0281304e: [Jack] Line In at Ext Front
> 
> ..or it certainly seems that all the inputs claim to have output
> capability too. Maybe this is what is confusing ALSA?

No.

Basically, the input/output amps mean the amp input to the widget
and the amp output from the widget, respectively.  They don't mean
that the playback or capture stream direction.  So, it's perfectly OK
if the amp is output for a capture stream.

One exception is the pin widget.  In this case, the input amp means
the amp applied for the input signal from this pin, and the output amp
means the amp applied before sending to this pin.  So, the
input/output actually corresponds to the stream direction.  But, for
other widgets, the amp I/O is just a difference between before or
after.


Takashi
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ