lkml.org 
[lkml]   [2008]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ALC883 recording troubles...
    Hi,

    On Thu, Jun 12, 2008 at 12:49 PM, Takashi Iwai <tiwai@suse.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@suse.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.

    With "Digital" at 0, changing "Capture" has no effect. However, with
    "Capture" at 0 and these values for "Digital":

    db gain -30 byte read 0x80
    db gain -28 byte read 0x81
    db gain -26 byte read 0x82
    db gain -22 byte read 0x83
    db gain -19 byte read 0x84
    db gain -17 byte read 0x85
    db gain -15 byte read 0x86
    db gain -13 byte read 0x87
    db gain -12 byte read 0x88
    db gain -11 byte read 0x89
    db gain -10 byte read 0x8a
    db gain -9 byte read 0x8b
    db gain -8 byte read 0x8d <-- up two here
    db gain -7 byte read 0x8e
    db gain -6 byte read 0x90
    db gain -5 byte read 0x92
    db gain -4 byte read 0x94
    db gain -3 byte read 0x97
    ...
    db gain 12 byte read 0xff
    db gain 13 (and up) byte read 0x00 <-- seems to flip over or get capped

    If I now change "Capture" to have dB gain 0 (35% in alsamixer), I get
    this instead (for different values of "Digital"):

    db gain -30 byte read 0x80
    db gain -29 byte read 0x85
    ...
    db gain -18 byte read 0x90
    ...
    db gain -12 byte read 0xa0
    ...
    db gain -6 byte read 0xc0
    ...
    db gain -1 byte read 0xf2

    So in fact, if both controls are at dB gain 0 (or one of them is
    higher), the only byte I can read is 0x00.

    > 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:

    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?

    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."

    Thanks!


    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


    \
     
     \ /
      Last update: 2008-06-12 15:07    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean