linux-kernel - Re: [alsa-devel] Bugs on aspire one A150

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:	Mon, 16 Mar 2009 19:06:38 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Andreas Mohr <andi@...as.de>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [alsa-devel] Bugs on aspire one A150

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?)


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

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