Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754448AbYFLPTQ (ORCPT ); Thu, 12 Jun 2008 11:19:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752070AbYFLPTA (ORCPT ); Thu, 12 Jun 2008 11:19:00 -0400 Received: from ns2.suse.de ([195.135.220.15]:48010 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbYFLPS7 (ORCPT ); Thu, 12 Jun 2008 11:18:59 -0400 Date: Thu, 12 Jun 2008 17:18:58 +0200 Message-ID: From: Takashi Iwai To: "Daniel J Blueman" Cc: "Vegard Nossum" , "Linux Kernel" Subject: Re: ALC883 recording troubles... In-Reply-To: <6278d2220806120758y38d9b431td3996a3cef73bb50@mail.gmail.com> References: <6278d2220806091259t47c9b070v269da0f5855ef014@mail.gmail.com> <19f34abd0806120603q2ddc6654r9562dfea556c2791@mail.gmail.com> <19f34abd0806120648j4f15b762r8e72c348c14b946f@mail.gmail.com> <19f34abd0806120655u75df09bfuaf33f1d54128b0b7@mail.gmail.com> <19f34abd0806120718g21ddfa3bjbf6f194aa1d3d37d@mail.gmail.com> <6278d2220806120758y38d9b431td3996a3cef73bb50@mail.gmail.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (x86_64-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3423 Lines: 82 At Thu, 12 Jun 2008 15:58:30 +0100, Daniel J Blueman wrote: > > On Thu, Jun 12, 2008 at 3:23 PM, Takashi Iwai wrote: > > At Thu, 12 Jun 2008 16:18:14 +0200, > > Vegard Nossum wrote: > >> > >> On Thu, Jun 12, 2008 at 4:02 PM, Takashi Iwai wrote: > >> > At Thu, 12 Jun 2008 15:55:45 +0200, > >> > Vegard Nossum wrote: > >> >> > >> >> On Thu, Jun 12, 2008 at 3:52 PM, Takashi Iwai wrote: > >> >> > At Thu, 12 Jun 2008 15:48:32 +0200, > >> >> > Vegard Nossum wrote: > >> >> >> > >> >> >> The external mic: > >> >> >> > >> >> >> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out > >> >> >> Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 > >> >> >> Amp-In vals: [0x00 0x00] > >> >> > > >> >> > The input volume is zero. Try to raise "Mic Boost" (if present)? > >> >> > >> >> They're already all up. > >> >> > >> >> Line In Boost = 100 > >> >> Mic Boost = 100 > >> >> Internal Mic Boost = 100 > >> >> > >> >> Right after changing all these to max, I've read the value from > >> >> card0/codec#0 again: > >> >> > >> >> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out > >> >> Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 > >> >> Amp-In vals: [0x00 0x00] > >> >> > >> >> There doesn't seem to be any difference. Even when changing them all > >> >> to 0 in alsamixer, this output stays the same. > >> > > >> > Weird. What happens if you execute the verb directly via hda-verb > >> > program like below? > >> > hda-verb /dev/snd/hwC0D0 0x18 SET_AMP 0x7002 > >> > > >> > >> Yep, this has the same effect has changing the "Mic Boost" control in > >> the Playback section of alsamixer. > >> > >> What I discovered now, though, is that I get a much wider range of > >> values from the external mic (so playback of the captured data > >> actually sounds correct). It actually works, but there is still a very > >> strong DC offset that seems dependent on the level of the "Capture" > >> control. This offset still makes it unusable for recording, since even > >> slightly louder noises will clip the samples. > >> > >> It also seems that this control is reset each time I start Audacity > >> (even though the "Mic boost" level in alsamixer doesn't change). But I > >> guess this unrelated to the DC offset issue. > >> > >> Changing the voltage level now (0x21, 0x22, 0x24, with Mic Boost at > >> 0x02) doesn't change the DC offset, but has the same effect as before > >> (the values fluctuate, but eventually stabilize at the same level). > > > > Hmm, then it's all what I can guess right now. > > There might be some vendor-specific settings I don't know of. > > Maybe. I can readily dump the PCI config space of the Intel HD-audio > controller in Windows and list differences; the datasheet from Intel > allows us to decode the registers. Will this help us any? Of course, > we really need to dump the target behind the HD-bus, but that's > another matter... I don't think it's an issue of PCI register but rather codec setups. PCI registers cannot influence on an analog thing like DC offset. So, we need to peek the HD-audio codec registers if really doing so. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/