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:	Tue, 17 Mar 2009 08:57:06 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Andreas Mohr <andi@...as.de>
Cc:	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

At Mon, 16 Mar 2009 22:22:27 +0100,
Andreas Mohr wrote:
> 
> Hi,
> 
> On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
> > At Mon, 16 Mar 2009 19:06:38 +0100,
> > Andreas Mohr wrote:
> > > 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.
> 
> Thought so.
> 
> > > 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.
> 
> Not sure what this means.
> 
> > 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.
> 
> I don't quite follow you here. Is there anything I could do about this?

The mic array on a laptop is used for beam forming and noise
suppressions.  These require the software manipulation, of course. 
The question is what kind of data is read from the hardware.  Thus,
providing the raw streams for both mic inputs makes sense.

Obviously the stream read from the codec chip is a PCM while usually
the digital mic gives the output as PDM.  So PDM -> PCM isn't needed
here.  But, still a question is why a phase inversion in the second
channel.  Whether it's intentional (e.g. to make the further
conversion easier) or not.

Would be interesting if you can figure out which digital-mic component
is used on your laptop (and if we can have any chip information by
luck).


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/