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]
Message-ID: <s5hfxhczinh.wl%tiwai@suse.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ