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]

Date:	Thu, 12 Jun 2008 15:12:59 +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 15:03:16 +0200,
Vegard Nossum wrote:
> 
> Hi,
> 
> On Thu, Jun 12, 2008 at 12:49 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > At Wed, 11 Jun 2008 20:00:17 +0100,
> > Daniel J Blueman wrote:
> >>
> >> On Tue, Jun 10, 2008 at 6:59 AM, Takashi Iwai <tiwai@...e.de> wrote:
> >> > At Mon, 9 Jun 2008 20:59:00 +0100,
> >> > Daniel J Blueman wrote:
> >> >>
> >> >> Hi Takashi-san,
> >> >>
> >> >> I'm experiencing DC offset with the microphone on 2.6.24 (Ubuntu 8.04
> >> >> LTS x86-64). I can see on Audacity that the DC offset that varies with
> >> >> the recording capture level.
> >> >
> >> > Could you elaborate?  The mic bias level could be changed via the pin
> >> > control value.  Usually, it's set as VREF 80%.
> >>
> >> When the recording->capture level is set to 0, the mic has no DC
> >> offset as expected. Maxing the recording->capture level, the mic input
> >> is saturated, in between, we see a linear connection.
> 
> I find that a good way to examine the captured PCM is the following command:
> 
>     $ arecord | od -t x1z -v
> 
> With the "Capture" and "Digital" controls both at 0 in alsamixer, this
> outputs just a constant 0x80 byte. This seems natural.

The "Digital Capture Volume" is the software attenuation/gain in
alsa-lib.  Keep it in the middle corresponding to 0dB.  Otherwise you
change the data digitally by the software.  This control exists for
some devices that have only digital mics and no hardware analog 
volume controls.

"Capture Volume" is the hardware recording level.


> > You can try to adjust VREF value of mic pins.
> > For example, the node 0x18 and 0x19 correspond to the rear and front
> > mics, respectively.  Then run the following as root:
> >
> >        # ./hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x21
> >
> > which will change the widget 0x18 (rear mic) to input-VREF 50%
> > (0x21).  The original value is input-VREF 80% (0x24).
> 
> I tried to do this for my card. For me, I need the 0x19 widget, which
> is the internal mic:

Did you try the external mic, too?

> Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
>   Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
>   Amp-In vals:  [0x00 0x00]
>   Pincap 0x083724: IN Detect
>     Vref caps: HIZ 50 GRD 80 100
>   Pin Default 0x99a30941: [Fixed] Mic at Int ATAPI
>     Conn = ATAPI, Color = Unknown
>     DefAssociation = 0x4, Sequence = 0x1
>     Misc = NO_PRESENCE
>   Pin-ctls: 0x24: IN VREF_80
>   Unsolicited: tag=00, enabled=0
> 
> And I tried various values for the PinCtl. 0x20, 0x21, and 0x22, (0x24
> was the default), but with no change in the input byte stream AT ALL!
> And I double-checked, my input source is set to "Internal Mic". (Just
> to be 100% sure, I tried all three input sources, but it was the same
> for all. So no change in the input at all.)
> 
> Do you have any more tips that I can try out?

Did you get ANY input from the internal mic?  If no, the pin mapping
might be wrong.  That is, 0x19 isn't the internal mic.

> Also, I am just curious, is it possible to break the microphone (or
> other physical components) by changing the voltage levels to
> unsupported values, or is it safe to experiment freely? I read this in
> the HDA specification:
> 
> "The VRefEn field encoding selects one of the possible states for the
> VRef signal(s). If the value written to this control does not
> correspond to a supported value as defined in the Pin Capabilities
> parameter, the control must either retain the previous value or take
> the value of 000, which will put the control in a Hi-Z state and
> prevent damage to any attached components."

There is no safe thing as long as you work as root :)

But, I've not heard any report that the wrong pin (at least VREF)
broke the whole circuit, though.


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/