Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758129AbZCPUaa (ORCPT ); Mon, 16 Mar 2009 16:30:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756598AbZCPUaU (ORCPT ); Mon, 16 Mar 2009 16:30:20 -0400 Received: from mail.suse.de ([195.135.220.2]:50608 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756036AbZCPUaT (ORCPT ); Mon, 16 Mar 2009 16:30:19 -0400 Date: Mon, 16 Mar 2009 21:28:39 +0100 Message-ID: From: Takashi Iwai To: Andreas Mohr Cc: Maxim Levitsky , linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Kernel Testers List Subject: Re: [alsa-devel] Bugs on aspire one A150 In-Reply-To: <20090316180638.GB25647@rhlx01.hs-esslingen.de> References: <20090316145036.GA26358@rhlx01.hs-esslingen.de> <20090316160208.GB4458@rhlx01.hs-esslingen.de> <20090316170015.GA9776@rhlx01.hs-esslingen.de> <20090316173000.GA25647@rhlx01.hs-esslingen.de> <20090316180638.GB25647@rhlx01.hs-esslingen.de> 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 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) 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: 3622 Lines: 92 At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote: > > On Mon, Mar 16, 2009 at 06:34:35PM +0100, Takashi Iwai wrote: > > At Mon, 16 Mar 2009 18:30:00 +0100, > > Andreas Mohr wrote: > > > > > > Hi, > > > > > > On Mon, Mar 16, 2009 at 06:15:39PM +0100, Takashi Iwai wrote: > > > > At Mon, 16 Mar 2009 18:00:15 +0100, > > > > Andreas Mohr wrote: > > > > > > > And, is the behavior consistent regardless of the value high, i.e. > > > > > > > the key is only whether the values for both channels are identical? > > > > > > > > > > > > BTW, what if you record with the following definition? > > > > > > Put the below to ~/.asoundrc > > > > > > > > > > > > pcm.imix { > > > > > > type plug > > > > > > slave.pcm "hw" > > > > > > ttable.0.0 0.5 > > > > > > ttable.0.1 -0.5 > > > > > > } > > > > > > > > > > > > and record like > > > > > > > > > > > > % aplay -Dimix -c1 foo.wav > > > > > > > > > > Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders > > > > > are acting normally, i.e. slider low == no sound), despite being a > > > > > "plug" type definition (this is what you wanted to discern, right? ;). > > > > > > > > Interesting. This implies that one channel is inverted indeed. > > > > > > Oh, you mean "inverted" as in "_hardware_ channel which provides opposite > > > sample values as compared to the other channel"? > > > > Right. My guess is that the hardware provides left (or right) channel > > is multiplied by -1 (yep "inverted" is no correct word choice). > > > > > > As default the alsa-lib plugin downmixes a stereo stream to a mono > > > > stream simply by left/2 + right/2. The above changes the routing > > > > policy as left/2 - right/2. > > > > > > That exactly matches my current stream of thought (while reading > > > "one channel is inverted" above). > > > > > > > So we need to pass some information to change this kind of thing... > > > > > > That's something specific to ALC268 codec setup, right? > > > ("ALC268 digital mic == left plus right channel, but inverted setup"?) > > > > No. It's specific to the digital-mic side. > > I just tried connecting a headset and switching to E-Mic. > What I can say is: > - opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?) > - leaving E-Mic unplugged will actually record from i-Mic (due to properly > working EAPD mechanism, right?) The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK. > BTW, the output (of arecord -Dplughw:0 -c2 -traw -fdat foo.wav) _does_ have > inverted channels: > > 00000130 2A 02 D2 FD 65 02 A5 FD 10 00 E7 FF 99 FF 72 00 *...e.........r. > 00000140 53 FE A7 01 ED FF 12 00 4F FF A6 00 86 00 81 FF S.......O....... > ... and so on in the entire file ... > > > One question still: is this a hardware defect (i.e. could this possibly > be swapped cables of the microphone connector in this model or so? > Not plausible but...), or is this an existing property > of the HDA's dig-mic base? You indicated it's the latter I think... My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array. The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data. 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/