From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC PATCH] Inverted internal mic Date: Tue, 28 Feb 2012 16:20:48 +0100 Message-ID: References: <4F4C9714.1080307@canonical.com> <4F4CA438.90103@canonical.com> <4F4CD1AF.2050409@canonical.com> <4F4CE264.7040008@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id B975E24686 for ; Tue, 28 Feb 2012 16:20:49 +0100 (CET) In-Reply-To: <4F4CE264.7040008@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: David Henningsson Cc: ALSA Development Mailing List , kailang@realtek.com, 903853@bugs.launchpad.net List-Id: alsa-devel@alsa-project.org At Tue, 28 Feb 2012 15:19:16 +0100, David Henningsson wrote: > > On 02/28/2012 02:22 PM, Takashi Iwai wrote: > > At Tue, 28 Feb 2012 14:07:59 +0100, > > David Henningsson wrote: > >> Ok. My question was more about the following: When I look at > >> patch_realtek.c, I can find functions alc271_fixup_dmic and > >> alc269_fixup_stereo_dmic. I have also seen machines having ALC268 and > >> ALC272X that have this internal mic behaviour. Is there a way we can > >> know the corresponding processing coefficients to set for ALC268 and > >> ALC272X as well? > > > > AFAIK, no, it was specific to the codec model. > > Ok, then we can only hope for Kailang to supply this information if > possible. And if not possible we could attempt the workaround (when/if > we agree on it...) for these devices as well? > > >>> Note that in alsa-lib, the HD-audio "default" is already set up to > >>> copy left-channel for mono streams. You can see a line setting > >>> "route_policy" to "copy" in HDA-Intel.conf. > >>> > >>> Thus, when ALSA apps run without PA, it'd work in both stereo and > >>> mono. > >> > >> Assuming the right channel is muted, yes. But not in the current > >> implementation. > > > > It should work no matter whether the right channel is muted or not. > > The plug layer will use only the left channel when a mono stream is > > recorded since route_policy=copy is set. Remember that it's about > > "default" PCM, not about "hw" PCM that PA uses. We don't touch "hw" > > intentionally because it's really intended to be a raw access. > > I'm talking about recording an internal mic in *stereo*, as I just wrote > below. Or don't you agree that is a valid and probably fairly common use > case? Well, when you record it in stereo, and play it back, then you hear the sound without problem. The problem happens only when you sum the left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal. > >> By not making a change in the ALSA layer, it will still be broken for > >> any ALSA apps who record the Internal Mic as a stereo signal. They will > >> get a broken result as the right channel will be phase inverted. That's > >> why I think this is better dealt with in the ALSA layer. > >> Would a zeroed right channel be less broken than a phase inverted right > >> channel? I think so. Takashi