[RFC PATCH] Inverted internal mic

[RFC PATCH] Inverted internal mic

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Hi,

One of the more common problems on laptop machines, is that the internal 
mic provides a stereo signal but with one channel phase inverted, or 
differential output.

This means problems for applications recording two channels but later 
merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, 
alsa-lib and PulseAudio layers. It's a matter of picking the right one. 
I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for
everyone, leading to no application being able to use both channels, 
even if they would implement some kind of 
"auto-detect-and-reverse-one-channel" functionality.

For the most part, this has been some Acer Aspire machines running 
Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we 
have proc coefs we can set, but for the other two these proc coefs, if 
they exist, are unknown to us.

Recently I came across a Conexant as well, and I decided to write a 
patch for it, that would take the approach that the internal mic is 
forced mono on the kcontrol, and make sure the right channel is always 
muted. The patch is verified by the reporter to fix this problem. It 
could use some perfection though - it would make sense to to the same to 
the internal mic boost as well, and the strcmp('Internal Mic') call 
could maybe be turned into something more elegant. But before going 
ahead with that, I'd like to hear your opinion on the matter, if you 
agree that this is a good approach to the problem?

References:

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachment/2631623/+files/alsa-info.txt.VmCN7lMBL4

https://bugs.launchpad.net/bugs/903853

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[-- Attachment #2: 0001-Fix-internal-mic-for-Lenovo-Ideapad-U300s.patch --]
[-- Type: text/x-patch, Size: 4831 bytes --]

>From 3ef2a105a85195c14e25190bca53bb55260feffa Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Fri, 24 Feb 2012 14:57:44 +0100
Subject: [PATCH] Fix internal mic for Lenovo Ideapad U300s

The internal mic input is phase inverted on one channel.
To avoid people in userspace summing the channels together
and get zero result, mute the right channel and make sure
they can't unmute it.

BugLink: https://bugs.launchpad.net/bugs/903853
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 sound/pci/hda/patch_conexant.c |   41 +++++++++++++++++++++++++++++----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 266e5a6..4a05817 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -140,6 +140,7 @@ struct conexant_spec {
 	unsigned int asus:1;
 	unsigned int pin_eapd_ctrls:1;
 	unsigned int single_adc_amp:1;
+	unsigned int fixup_stereo_dmic:1;
 
 	unsigned int adc_switching:1;
 
@@ -4044,7 +4045,7 @@ static int cx_auto_init(struct hda_codec *codec)
 
 static int cx_auto_add_volume_idx(struct hda_codec *codec, const char *basename,
 			      const char *dir, int cidx,
-			      hda_nid_t nid, int hda_dir, int amp_idx)
+			      hda_nid_t nid, int hda_dir, int amp_idx, int chs)
 {
 	static char name[32];
 	static struct snd_kcontrol_new knew[] = {
@@ -4056,7 +4057,7 @@ static int cx_auto_add_volume_idx(struct hda_codec *codec, const char *basename,
 
 	for (i = 0; i < 2; i++) {
 		struct snd_kcontrol *kctl;
-		knew[i].private_value = HDA_COMPOSE_AMP_VAL(nid, 3, amp_idx,
+		knew[i].private_value = HDA_COMPOSE_AMP_VAL(nid, chs, amp_idx,
 							    hda_dir);
 		knew[i].subdevice = HDA_SUBDEV_AMP_FLAG;
 		knew[i].index = cidx;
@@ -4074,7 +4075,7 @@ static int cx_auto_add_volume_idx(struct hda_codec *codec, const char *basename,
 }
 
 #define cx_auto_add_volume(codec, str, dir, cidx, nid, hda_dir)		\
-	cx_auto_add_volume_idx(codec, str, dir, cidx, nid, hda_dir, 0)
+	cx_auto_add_volume_idx(codec, str, dir, cidx, nid, hda_dir, 0, 3)
 
 #define cx_auto_add_pb_volume(codec, nid, str, idx)			\
 	cx_auto_add_volume(codec, str, " Playback", idx, nid, HDA_OUTPUT)
@@ -4152,14 +4153,22 @@ static int cx_auto_add_capture_volume(struct hda_codec *codec, hda_nid_t nid,
 	int i;
 
 	for (i = 0; i < spec->num_adc_nids; i++) {
+		int chs = 3;
 		hda_nid_t adc_nid = spec->adc_nids[i];
 		int idx = get_input_connection(codec, adc_nid, nid);
 		if (idx < 0)
 			continue;
 		if (spec->single_adc_amp)
 			idx = 0;
+
+		if (spec->fixup_stereo_dmic && (strcmp("Internal Mic", label) == 0)) {
+			/* Make left channel controllable and right channel muted */
+			chs = 1;
+			snd_hda_codec_write_cache(codec, adc_nid, 0, AC_VERB_SET_AMP_GAIN_MUTE, 
+				AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT | (idx << AC_AMP_SET_INDEX_SHIFT) | AC_AMP_MUTE);
+		}
 		return cx_auto_add_volume_idx(codec, label, pfx,
-					      cidx, adc_nid, HDA_INPUT, idx);
+					      cidx, adc_nid, HDA_INPUT, idx, chs);
 	}
 	return 0;
 }
@@ -4335,22 +4344,30 @@ static void apply_pincfg(struct hda_codec *codec, const struct cxt_pincfg *cfg)
 
 }
 
-static void apply_pin_fixup(struct hda_codec *codec,
+enum {
+	CXT_PINCFG_LENOVO_X200,
+	CXT_FIXUP_STEREO_DMIC,
+};
+
+static void apply_fixup(struct hda_codec *codec,
 			    const struct snd_pci_quirk *quirk,
 			    const struct cxt_pincfg **table)
 {
+	struct conexant_spec *spec = codec->spec;
+
 	quirk = snd_pci_quirk_lookup(codec->bus->pci, quirk);
-	if (quirk) {
+	if (quirk && table[quirk->value]) {
 		snd_printdd(KERN_INFO "hda_codec: applying pincfg for %s\n",
 			    quirk->name);
 		apply_pincfg(codec, table[quirk->value]);
 	}
+	if (quirk->value == CXT_FIXUP_STEREO_DMIC) {
+		snd_printdd(KERN_INFO "hda_codec: applying internal mic workaround for %s\n",
+			    quirk->name);
+		spec->fixup_stereo_dmic = 1;
+	}
 }
 
-enum {
-	CXT_PINCFG_LENOVO_X200,
-};
-
 static const struct cxt_pincfg cxt_pincfg_lenovo_x200[] = {
 	{ 0x16, 0x042140ff }, /* HP (seq# overridden) */
 	{ 0x17, 0x21a11000 }, /* dock-mic */
@@ -4360,10 +4377,12 @@ static const struct cxt_pincfg cxt_pincfg_lenovo_x200[] = {
 
 static const struct cxt_pincfg *cxt_pincfg_tbl[] = {
 	[CXT_PINCFG_LENOVO_X200] = cxt_pincfg_lenovo_x200,
+	[CXT_FIXUP_STEREO_DMIC] = NULL,
 };
 
 static const struct snd_pci_quirk cxt_fixups[] = {
 	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo X200", CXT_PINCFG_LENOVO_X200),
+	SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
 	{}
 };
 
@@ -4387,7 +4406,7 @@ static int patch_conexant_auto(struct hda_codec *codec)
 		break;
 	}
 
-	apply_pin_fixup(codec, cxt_fixups, cxt_pincfg_tbl);
+	apply_fixup(codec, cxt_fixups, cxt_pincfg_tbl);
 
 	err = cx_auto_search_adcs(codec);
 	if (err < 0)
-- 
1.7.9


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 28 Feb 2012 09:57:56 +0100,
David Henningsson wrote:
> 
> Hi,
> 
> One of the more common problems on laptop machines, is that the internal 
> mic provides a stereo signal but with one channel phase inverted, or 
> differential output.
> 
> This means problems for applications recording two channels but later 
> merging them into one, leaving them with zero or near-zero output.
> 
> There are various ways we can work around this in both the kernel, 
> alsa-lib and PulseAudio layers. It's a matter of picking the right one. 
> I'm leaning towards trying to fix it in the kernel's codec drivers, because
> 1) we already have quirking infrastructure there
> 2) we already have some working quirks already in that layer
> 3) it would benefit other sound applications that use ALSA directly.
> 
> The downside to that is really that we're silencing out one channel for
> everyone, leading to no application being able to use both channels, 
> even if they would implement some kind of 
> "auto-detect-and-reverse-one-channel" functionality.
> 
> For the most part, this has been some Acer Aspire machines running 
> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we 
> have proc coefs we can set, but for the other two these proc coefs, if 
> they exist, are unknown to us.
> 
> Recently I came across a Conexant as well, and I decided to write a 
> patch for it, that would take the approach that the internal mic is 
> forced mono on the kcontrol, and make sure the right channel is always 
> muted. The patch is verified by the reporter to fix this problem. It 
> could use some perfection though - it would make sense to to the same to 
> the internal mic boost as well, and the strcmp('Internal Mic') call 
> could maybe be turned into something more elegant. But before going 
> ahead with that, I'd like to hear your opinion on the matter, if you 
> agree that this is a good approach to the problem?

The remaining problem in the patch is that the signal is recorded only
on left when you record in stereo.  I guess the reporter tested only a
program like Skype, which uses only a mono stream.

If this behavior, only one channel in a stereo stream, is acceptable,
it's a reasonable fix, I think.


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 02/28/2012 10:24 AM, Takashi Iwai wrote:
> At Tue, 28 Feb 2012 09:57:56 +0100,
> David Henningsson wrote:
>>
>> Hi,
>>
>> One of the more common problems on laptop machines, is that the internal
>> mic provides a stereo signal but with one channel phase inverted, or
>> differential output.
>>
>> This means problems for applications recording two channels but later
>> merging them into one, leaving them with zero or near-zero output.
>>
>> There are various ways we can work around this in both the kernel,
>> alsa-lib and PulseAudio layers. It's a matter of picking the right one.
>> I'm leaning towards trying to fix it in the kernel's codec drivers, because
>> 1) we already have quirking infrastructure there
>> 2) we already have some working quirks already in that layer
>> 3) it would benefit other sound applications that use ALSA directly.
>>
>> The downside to that is really that we're silencing out one channel for
>> everyone, leading to no application being able to use both channels,
>> even if they would implement some kind of
>> "auto-detect-and-reverse-one-channel" functionality.
>>
>> For the most part, this has been some Acer Aspire machines running
>> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we
>> have proc coefs we can set, but for the other two these proc coefs, if
>> they exist, are unknown to us.

A follow-up question here would be if it is easy for you (or Kailang?) 
to figure this out, or if we should resort to the suggest workaround for 
Realtek ALC268 and ALC272X as well?

>> Recently I came across a Conexant as well, and I decided to write a
>> patch for it, that would take the approach that the internal mic is
>> forced mono on the kcontrol, and make sure the right channel is always
>> muted. The patch is verified by the reporter to fix this problem. It
>> could use some perfection though - it would make sense to to the same to
>> the internal mic boost as well, and the strcmp('Internal Mic') call
>> could maybe be turned into something more elegant. But before going
>> ahead with that, I'd like to hear your opinion on the matter, if you
>> agree that this is a good approach to the problem?
>
> The remaining problem in the patch is that the signal is recorded only
> on left when you record in stereo.  I guess the reporter tested only a
> program like Skype, which uses only a mono stream.
>
> If this behavior, only one channel in a stereo stream, is acceptable,
> it's a reasonable fix, I think.

That is indeed a disadvantage, but I don't know if we have something 
better to offer? E g, we could try an alsa-lib ttable solution, but that 
would then have a problem with knowing whether the Internal Mic is 
currently selected or not.

If the program:

- tries to record in mono:
   * As the industry standard for mapping mono is to map it to the left 
channel, I assume this is what ALSA/HDA does in this case as well, so 
unchanged and working behaviour

- record in stereo, then take left channel only:
   * unchanged and working behaviour

- record in stereo, then take right channel only:
   * regression as the inverted channel will now be zero, but this would 
be highly unconventional and unusual, I assume?

- record in stereo, then merge both channels:
   * this is the normal and common case for VoIP applications going 
through PulseAudio (Skype etc). Improvement, this will fix the bug; 
although the result will be -6 dB compared to the original signal.

- record in stereo, keep signal in stereo for playback:
   * this somewhat depends on how the playback is set up, but I would 
say that it would be an improvement in most cases if the speakers are 
relatively close to one another...I guess?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 28 Feb 2012 10:54:00 +0100,
David Henningsson wrote:
> 
> On 02/28/2012 10:24 AM, Takashi Iwai wrote:
> > At Tue, 28 Feb 2012 09:57:56 +0100,
> > David Henningsson wrote:
> >>
> >> Hi,
> >>
> >> One of the more common problems on laptop machines, is that the internal
> >> mic provides a stereo signal but with one channel phase inverted, or
> >> differential output.
> >>
> >> This means problems for applications recording two channels but later
> >> merging them into one, leaving them with zero or near-zero output.
> >>
> >> There are various ways we can work around this in both the kernel,
> >> alsa-lib and PulseAudio layers. It's a matter of picking the right one.
> >> I'm leaning towards trying to fix it in the kernel's codec drivers, because
> >> 1) we already have quirking infrastructure there
> >> 2) we already have some working quirks already in that layer
> >> 3) it would benefit other sound applications that use ALSA directly.
> >>
> >> The downside to that is really that we're silencing out one channel for
> >> everyone, leading to no application being able to use both channels,
> >> even if they would implement some kind of
> >> "auto-detect-and-reverse-one-channel" functionality.
> >>
> >> For the most part, this has been some Acer Aspire machines running
> >> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we
> >> have proc coefs we can set, but for the other two these proc coefs, if
> >> they exist, are unknown to us.
> 
> A follow-up question here would be if it is easy for you (or Kailang?) 
> to figure this out, or if we should resort to the suggest workaround for 
> Realtek ALC268 and ALC272X as well?

Actually, Kailang (Cc'ed now) and I talked about it when I visited
Taipei in the last year, and he mentioned that there is no way to
detect the FM chip from the codec.  It seems that SSID listing is the
only way.

> >> Recently I came across a Conexant as well, and I decided to write a
> >> patch for it, that would take the approach that the internal mic is
> >> forced mono on the kcontrol, and make sure the right channel is always
> >> muted. The patch is verified by the reporter to fix this problem. It
> >> could use some perfection though - it would make sense to to the same to
> >> the internal mic boost as well, and the strcmp('Internal Mic') call
> >> could maybe be turned into something more elegant. But before going
> >> ahead with that, I'd like to hear your opinion on the matter, if you
> >> agree that this is a good approach to the problem?
> >
> > The remaining problem in the patch is that the signal is recorded only
> > on left when you record in stereo.  I guess the reporter tested only a
> > program like Skype, which uses only a mono stream.
> >
> > If this behavior, only one channel in a stereo stream, is acceptable,
> > it's a reasonable fix, I think.
> 
> That is indeed a disadvantage, but I don't know if we have something 
> better to offer? E g, we could try an alsa-lib ttable solution, but that 
> would then have a problem with knowing whether the Internal Mic is 
> currently selected or not.

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.

> If the program:
> 
> - tries to record in mono:
>    * As the industry standard for mapping mono is to map it to the left 
> channel, I assume this is what ALSA/HDA does in this case as well, so 
> unchanged and working behaviour
> 
> - record in stereo, then take left channel only:
>    * unchanged and working behaviour
> 
> - record in stereo, then take right channel only:
>    * regression as the inverted channel will now be zero, but this would 
> be highly unconventional and unusual, I assume?
> 
> - record in stereo, then merge both channels:
>    * this is the normal and common case for VoIP applications going 
> through PulseAudio (Skype etc). Improvement, this will fix the bug; 
> although the result will be -6 dB compared to the original signal.
> 
> - record in stereo, keep signal in stereo for playback:
>    * this somewhat depends on how the playback is set up, but I would 
> say that it would be an improvement in most cases if the speakers are 
> relatively close to one another...I guess?

Well, I think this could be also worked around in PA.  Can PA switch
the downmixing to the mono to a simple left-channel copy, only for
certain devices, or at least via a config?

If this is feasible, the rest is how to identify such a device.
And this can be done equally well in user-space, too, as there is no
hidden information about it.

Of course, this is not the best of the best.  Ideally, the driver
provides multiple PCM streams and PA switches between them and
switches the downmixing simultaneously per input-source change.
But this needs a lot of works, and maybe requires a fundamental
infrastructure change, too.


thanks,

Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 02/28/2012 11:38 AM, Takashi Iwai wrote:
> At Tue, 28 Feb 2012 10:54:00 +0100,
> David Henningsson wrote:
>>
>> On 02/28/2012 10:24 AM, Takashi Iwai wrote:
>>> At Tue, 28 Feb 2012 09:57:56 +0100,
>>> David Henningsson wrote:
>>>>
>>>> Hi,
>>>>
>>>> One of the more common problems on laptop machines, is that the internal
>>>> mic provides a stereo signal but with one channel phase inverted, or
>>>> differential output.
>>>>
>>>> This means problems for applications recording two channels but later
>>>> merging them into one, leaving them with zero or near-zero output.
>>>>
>>>> There are various ways we can work around this in both the kernel,
>>>> alsa-lib and PulseAudio layers. It's a matter of picking the right one.
>>>> I'm leaning towards trying to fix it in the kernel's codec drivers, because
>>>> 1) we already have quirking infrastructure there
>>>> 2) we already have some working quirks already in that layer
>>>> 3) it would benefit other sound applications that use ALSA directly.
>>>>
>>>> The downside to that is really that we're silencing out one channel for
>>>> everyone, leading to no application being able to use both channels,
>>>> even if they would implement some kind of
>>>> "auto-detect-and-reverse-one-channel" functionality.
>>>>
>>>> For the most part, this has been some Acer Aspire machines running
>>>> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we
>>>> have proc coefs we can set, but for the other two these proc coefs, if
>>>> they exist, are unknown to us.
>>
>> A follow-up question here would be if it is easy for you (or Kailang?)
>> to figure this out, or if we should resort to the suggest workaround for
>> Realtek ALC268 and ALC272X as well?
>
> Actually, Kailang (Cc'ed now) and I talked about it when I visited
> Taipei in the last year, and he mentioned that there is no way to
> detect the FM chip from the codec.  It seems that SSID listing is the
> only way.

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?

>>>> Recently I came across a Conexant as well, and I decided to write a
>>>> patch for it, that would take the approach that the internal mic is
>>>> forced mono on the kcontrol, and make sure the right channel is always
>>>> muted. The patch is verified by the reporter to fix this problem. It
>>>> could use some perfection though - it would make sense to to the same to
>>>> the internal mic boost as well, and the strcmp('Internal Mic') call
>>>> could maybe be turned into something more elegant. But before going
>>>> ahead with that, I'd like to hear your opinion on the matter, if you
>>>> agree that this is a good approach to the problem?
>>>
>>> The remaining problem in the patch is that the signal is recorded only
>>> on left when you record in stereo.  I guess the reporter tested only a
>>> program like Skype, which uses only a mono stream.
>>>
>>> If this behavior, only one channel in a stereo stream, is acceptable,
>>> it's a reasonable fix, I think.
>>
>> That is indeed a disadvantage, but I don't know if we have something
>> better to offer? E g, we could try an alsa-lib ttable solution, but that
>> would then have a problem with knowing whether the Internal Mic is
>> currently selected or not.
>
> 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.

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.

>> If the program:
>>
>> - tries to record in mono:
>>     * As the industry standard for mapping mono is to map it to the left
>> channel, I assume this is what ALSA/HDA does in this case as well, so
>> unchanged and working behaviour
>>
>> - record in stereo, then take left channel only:
>>     * unchanged and working behaviour
>>
>> - record in stereo, then take right channel only:
>>     * regression as the inverted channel will now be zero, but this would
>> be highly unconventional and unusual, I assume?
>>
>> - record in stereo, then merge both channels:
>>     * this is the normal and common case for VoIP applications going
>> through PulseAudio (Skype etc). Improvement, this will fix the bug;
>> although the result will be -6 dB compared to the original signal.
>>
>> - record in stereo, keep signal in stereo for playback:
>>     * this somewhat depends on how the playback is set up, but I would
>> say that it would be an improvement in most cases if the speakers are
>> relatively close to one another...I guess?
>
> Well, I think this could be also worked around in PA.  Can PA switch
> the downmixing to the mono to a simple left-channel copy, only for
> certain devices, or at least via a config?
>
> If this is feasible, the rest is how to identify such a device.
> And this can be done equally well in user-space, too, as there is no
> hidden information about it.

PA has udev rules to identify the device, so I'm not too worried about 
the identification, though that is generally frowned upon - I'd say that 
hardware dependent stuff should be in ALSA rather than PA. The 
difficulty is that we need to switch this on and off when we switch 
ports - we don't want to regress behaviour for e g line in and other 
stereo recording sources.

> Of course, this is not the best of the best.  Ideally, the driver
> provides multiple PCM streams and PA switches between them and
> switches the downmixing simultaneously per input-source change.
> But this needs a lot of works, and maybe requires a fundamental
> infrastructure change, too.

Seems almost easier to write a PulseAudio module that automatically 
detects when one channel is phase inverted, and inverts that channel 
when that happens. But maybe that is ugly too...

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
> 
> On 02/28/2012 11:38 AM, Takashi Iwai wrote:
> > At Tue, 28 Feb 2012 10:54:00 +0100,
> > David Henningsson wrote:
> >>
> >> On 02/28/2012 10:24 AM, Takashi Iwai wrote:
> >>> At Tue, 28 Feb 2012 09:57:56 +0100,
> >>> David Henningsson wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> One of the more common problems on laptop machines, is that the internal
> >>>> mic provides a stereo signal but with one channel phase inverted, or
> >>>> differential output.
> >>>>
> >>>> This means problems for applications recording two channels but later
> >>>> merging them into one, leaving them with zero or near-zero output.
> >>>>
> >>>> There are various ways we can work around this in both the kernel,
> >>>> alsa-lib and PulseAudio layers. It's a matter of picking the right one.
> >>>> I'm leaning towards trying to fix it in the kernel's codec drivers, because
> >>>> 1) we already have quirking infrastructure there
> >>>> 2) we already have some working quirks already in that layer
> >>>> 3) it would benefit other sound applications that use ALSA directly.
> >>>>
> >>>> The downside to that is really that we're silencing out one channel for
> >>>> everyone, leading to no application being able to use both channels,
> >>>> even if they would implement some kind of
> >>>> "auto-detect-and-reverse-one-channel" functionality.
> >>>>
> >>>> For the most part, this has been some Acer Aspire machines running
> >>>> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we
> >>>> have proc coefs we can set, but for the other two these proc coefs, if
> >>>> they exist, are unknown to us.
> >>
> >> A follow-up question here would be if it is easy for you (or Kailang?)
> >> to figure this out, or if we should resort to the suggest workaround for
> >> Realtek ALC268 and ALC272X as well?
> >
> > Actually, Kailang (Cc'ed now) and I talked about it when I visited
> > Taipei in the last year, and he mentioned that there is no way to
> > detect the FM chip from the codec.  It seems that SSID listing is the
> > only way.
> 
> 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.

> >>>> Recently I came across a Conexant as well, and I decided to write a
> >>>> patch for it, that would take the approach that the internal mic is
> >>>> forced mono on the kcontrol, and make sure the right channel is always
> >>>> muted. The patch is verified by the reporter to fix this problem. It
> >>>> could use some perfection though - it would make sense to to the same to
> >>>> the internal mic boost as well, and the strcmp('Internal Mic') call
> >>>> could maybe be turned into something more elegant. But before going
> >>>> ahead with that, I'd like to hear your opinion on the matter, if you
> >>>> agree that this is a good approach to the problem?
> >>>
> >>> The remaining problem in the patch is that the signal is recorded only
> >>> on left when you record in stereo.  I guess the reporter tested only a
> >>> program like Skype, which uses only a mono stream.
> >>>
> >>> If this behavior, only one channel in a stereo stream, is acceptable,
> >>> it's a reasonable fix, I think.
> >>
> >> That is indeed a disadvantage, but I don't know if we have something
> >> better to offer? E g, we could try an alsa-lib ttable solution, but that
> >> would then have a problem with knowing whether the Internal Mic is
> >> currently selected or not.
> >
> > 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.

> 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.
> 
> >> If the program:
> >>
> >> - tries to record in mono:
> >>     * As the industry standard for mapping mono is to map it to the left
> >> channel, I assume this is what ALSA/HDA does in this case as well, so
> >> unchanged and working behaviour
> >>
> >> - record in stereo, then take left channel only:
> >>     * unchanged and working behaviour
> >>
> >> - record in stereo, then take right channel only:
> >>     * regression as the inverted channel will now be zero, but this would
> >> be highly unconventional and unusual, I assume?
> >>
> >> - record in stereo, then merge both channels:
> >>     * this is the normal and common case for VoIP applications going
> >> through PulseAudio (Skype etc). Improvement, this will fix the bug;
> >> although the result will be -6 dB compared to the original signal.
> >>
> >> - record in stereo, keep signal in stereo for playback:
> >>     * this somewhat depends on how the playback is set up, but I would
> >> say that it would be an improvement in most cases if the speakers are
> >> relatively close to one another...I guess?
> >
> > Well, I think this could be also worked around in PA.  Can PA switch
> > the downmixing to the mono to a simple left-channel copy, only for
> > certain devices, or at least via a config?
> >
> > If this is feasible, the rest is how to identify such a device.
> > And this can be done equally well in user-space, too, as there is no
> > hidden information about it.
> 
> PA has udev rules to identify the device, so I'm not too worried about 
> the identification, though that is generally frowned upon - I'd say that 
> hardware dependent stuff should be in ALSA rather than PA.

It's actually already handled in ALSA.  It's just PA that ignores it
via "hw" PCM :)  Of course, I don't mean that the handling in alsa-lib
config is perfect, and it's a workaround.

> The 
> difficulty is that we need to switch this on and off when we switch 
> ports - we don't want to regress behaviour for e g line in and other 
> stereo recording sources.

Yes, that's the problem.

> > Of course, this is not the best of the best.  Ideally, the driver
> > provides multiple PCM streams and PA switches between them and
> > switches the downmixing simultaneously per input-source change.
> > But this needs a lot of works, and maybe requires a fundamental
> > infrastructure change, too.
> 
> Seems almost easier to write a PulseAudio module that automatically 
> detects when one channel is phase inverted, and inverts that channel 
> when that happens. But maybe that is ugly too...

Yes.  I don't think it's appropriate, too.


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

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?

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

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

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

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 02/28/2012 04:20 PM, Takashi Iwai wrote:
>> 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.

That could definitely be questioned: depending on the distance between 
speakers when you're finally playing it back, you might lose bass 
frequencies [1]. (That said, I'm not sure how much bass these mics pick 
up anyway.)

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

So the official recommendation is that summing left and right to make a 
mono signal, is to be considered an invalid operation?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[1] Or possibly get distorted sound in different ways, not sure.

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 28 Feb 2012 19:11:15 +0100,
David Henningsson wrote:
> 
> On 02/28/2012 04:20 PM, Takashi Iwai wrote:
> >> 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.
> 
> That could definitely be questioned: depending on the distance between 
> speakers when you're finally playing it back, you might lose bass 
> frequencies [1]. (That said, I'm not sure how much bass these mics pick 
> up anyway.)

Well, it might be, in the worst case.

> > 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.
> 
> So the official recommendation is that summing left and right to make a 
> mono signal, is to be considered an invalid operation?

It's not invalid in general but invalid for this digital mic.  That's
the only point.  Thus, avoiding summing only for known bad devices is
also a way to go, IMO.  It'd work more or less stably.
OTOH, muting the right reduces the risk but it also has a problem of
the lower volume and the lack of right signal in stereo streams, both
of which aren't easily avoided.

So we need to find some point of compromise...


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 02/28/2012 08:42 PM, Takashi Iwai wrote:
> At Tue, 28 Feb 2012 19:11:15 +0100,
> David Henningsson wrote:
>>
>> On 02/28/2012 04:20 PM, Takashi Iwai wrote:
>>>> 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.
>>
>> That could definitely be questioned: depending on the distance between
>> speakers when you're finally playing it back, you might lose bass
>> frequencies [1]. (That said, I'm not sure how much bass these mics pick
>> up anyway.)
>
> Well, it might be, in the worst case.
>
>>> 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.
>>
>> So the official recommendation is that summing left and right to make a
>> mono signal, is to be considered an invalid operation?
>
> It's not invalid in general but invalid for this digital mic.  That's
> the only point.  Thus, avoiding summing only for known bad devices is
> also a way to go, IMO.  It'd work more or less stably.
> OTOH, muting the right reduces the risk but it also has a problem of
> the lower volume and the lack of right signal in stereo streams, both
> of which aren't easily avoided.
>
> So we need to find some point of compromise...

Avoiding summing only for known bad devices and only when mixer is set 
to capture Internal Mic, is a quite complex condition that would have to 
implemented in not only PulseAudio, but every application using ALSA 
directly. (Well, and wants to either sum, or to avoid loss of bass and 
strange stereo effects.)

The lower volume problem is also an argument only if you want to sum the 
signal; so in this case it's lower volume against a cancelled signal 
altogether, in which case lower volume is better.

That leaves the lack of right signal in stereo streams, as a 
disadvantage with the proposed solution. In which use cases do you think 
this is a problem?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Wed, 29 Feb 2012 10:21:35 +0100,
David Henningsson wrote:
> 
> On 02/28/2012 08:42 PM, Takashi Iwai wrote:
> > At Tue, 28 Feb 2012 19:11:15 +0100,
> > David Henningsson wrote:
> >>
> >> On 02/28/2012 04:20 PM, Takashi Iwai wrote:
> >>>> 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.
> >>
> >> That could definitely be questioned: depending on the distance between
> >> speakers when you're finally playing it back, you might lose bass
> >> frequencies [1]. (That said, I'm not sure how much bass these mics pick
> >> up anyway.)
> >
> > Well, it might be, in the worst case.
> >
> >>> 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.
> >>
> >> So the official recommendation is that summing left and right to make a
> >> mono signal, is to be considered an invalid operation?
> >
> > It's not invalid in general but invalid for this digital mic.  That's
> > the only point.  Thus, avoiding summing only for known bad devices is
> > also a way to go, IMO.  It'd work more or less stably.
> > OTOH, muting the right reduces the risk but it also has a problem of
> > the lower volume and the lack of right signal in stereo streams, both
> > of which aren't easily avoided.
> >
> > So we need to find some point of compromise...
> 
> Avoiding summing only for known bad devices and only when mixer is set 
> to capture Internal Mic, is a quite complex condition that would have to 
> implemented in not only PulseAudio, but every application using ALSA 
> directly. (Well, and wants to either sum, or to avoid loss of bass and 
> strange stereo effects.)

As mentioned, ALSA-native "default" doesn't sum for mono signals.
It's not optimal for stereo, yeah, but better than summing blindly.

> The lower volume problem is also an argument only if you want to sum the 
> signal; so in this case it's lower volume against a cancelled signal 
> altogether, in which case lower volume is better.

Of course.  But my comparison is "pick up only left" vs "sum but
right-mute".  In the latter case, the lower volume happens also in
stereo streams (as a total volume), too.

> That leaves the lack of right signal in stereo streams, as a 
> disadvantage with the proposed solution. In which use cases do you think 
> this is a problem?

Honestly, I don't know.  It sounds really like a user's preference to
me.

BTW, it'd be possible to give some offsets to the internal mic capture
volume to compensate the lack of a stream.  Or, to make this behavior
selective via a mixer control.  In either way (especially the latter)
will make the code more complex.  So the question still remains: how
much compromise.


thanks,

Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 02/29/2012 10:56 AM, Takashi Iwai wrote:
> At Wed, 29 Feb 2012 10:21:35 +0100,
> David Henningsson wrote:
>>
>> On 02/28/2012 08:42 PM, Takashi Iwai wrote:
>>> At Tue, 28 Feb 2012 19:11:15 +0100,
>>> David Henningsson wrote:
>>>>
>>>> On 02/28/2012 04:20 PM, Takashi Iwai wrote:
>>>>>> 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.
>>>>
>>>> That could definitely be questioned: depending on the distance between
>>>> speakers when you're finally playing it back, you might lose bass
>>>> frequencies [1]. (That said, I'm not sure how much bass these mics pick
>>>> up anyway.)
>>>
>>> Well, it might be, in the worst case.
>>>
>>>>> 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.
>>>>
>>>> So the official recommendation is that summing left and right to make a
>>>> mono signal, is to be considered an invalid operation?
>>>
>>> It's not invalid in general but invalid for this digital mic.  That's
>>> the only point.  Thus, avoiding summing only for known bad devices is
>>> also a way to go, IMO.  It'd work more or less stably.
>>> OTOH, muting the right reduces the risk but it also has a problem of
>>> the lower volume and the lack of right signal in stereo streams, both
>>> of which aren't easily avoided.
>>>
>>> So we need to find some point of compromise...
>>
>> Avoiding summing only for known bad devices and only when mixer is set
>> to capture Internal Mic, is a quite complex condition that would have to
>> implemented in not only PulseAudio, but every application using ALSA
>> directly. (Well, and wants to either sum, or to avoid loss of bass and
>> strange stereo effects.)
>
> As mentioned, ALSA-native "default" doesn't sum for mono signals.
> It's not optimal for stereo, yeah, but better than summing blindly.
>
>> The lower volume problem is also an argument only if you want to sum the
>> signal; so in this case it's lower volume against a cancelled signal
>> altogether, in which case lower volume is better.
>
> Of course.  But my comparison is "pick up only left" vs "sum but
> right-mute".  In the latter case, the lower volume happens also in
> stereo streams (as a total volume), too.
>
>> That leaves the lack of right signal in stereo streams, as a
>> disadvantage with the proposed solution. In which use cases do you think
>> this is a problem?
>
> Honestly, I don't know.  It sounds really like a user's preference to
> me.

Ok.

> BTW, it'd be possible to give some offsets to the internal mic capture
> volume to compensate the lack of a stream.

Hmm...could you elaborate on this? What type of offsets are you 
referring to?

> Or, to make this behavior
> selective via a mixer control.  In either way (especially the latter)
> will make the code more complex.  So the question still remains: how
> much compromise.


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Raymond Yau]

2012/2/28, David Henningsson <david.henningsson@canonical.com>:
> Hi,
>
> Recently I came across a Conexant as well, and I decided to write a
> patch for it, that would take the approach that the internal mic is
> forced mono on the kcontrol, and make sure the right channel is always
> muted. The patch is verified by the reporter to fix this problem. It
> could use some perfection though - it would make sense to to the same to
> the internal mic boost as well, and the strcmp('Internal Mic') call
> could maybe be turned into something more elegant. But before going
> ahead with that, I'd like to hear your opinion on the matter, if you
> agree that this is a good approach to the problem?
>
> References:
>
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachment/2631623/+files/alsa-info.txt.VmCN7lMBL4
>
> https://bugs.launchpad.net/bugs/903853
>

Refer to the codec info

It seem that there is a path from [Audio Output]  0x10 through 0x24 to
[Audio Input]

Is there any technical reason for not implement "Stereo Mix" as "Input Source" ?


Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
  Control: name="Master Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Device: name="CONEXANT Analog", type="Audio", device=0
  Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
  Amp-Out vals:  [0x4a 0x4a]
  Converter: stream=8, channel=0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0



Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
  Device: name="CONEXANT Analog", type="Audio", device=0
  Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1
  Amp-In vals:  [0x50 0x50] [0x80 0x80] [0x50 0x50] [0x80 0x80]
  Converter: stream=4, channel=0
  SDI-Select: 0
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0
  Connection: 4
     0x17 0x18 0x23* 0x24





Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In
  Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x10 0x11

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Wed, 29 Feb 2012 11:45:40 +0100,
David Henningsson wrote:
> 
> On 02/29/2012 10:56 AM, Takashi Iwai wrote:
> > At Wed, 29 Feb 2012 10:21:35 +0100,
> > David Henningsson wrote:
> >>
> >> On 02/28/2012 08:42 PM, Takashi Iwai wrote:
> >>> At Tue, 28 Feb 2012 19:11:15 +0100,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 02/28/2012 04:20 PM, Takashi Iwai wrote:
> >>>>>> 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.
> >>>>
> >>>> That could definitely be questioned: depending on the distance between
> >>>> speakers when you're finally playing it back, you might lose bass
> >>>> frequencies [1]. (That said, I'm not sure how much bass these mics pick
> >>>> up anyway.)
> >>>
> >>> Well, it might be, in the worst case.
> >>>
> >>>>> 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.
> >>>>
> >>>> So the official recommendation is that summing left and right to make a
> >>>> mono signal, is to be considered an invalid operation?
> >>>
> >>> It's not invalid in general but invalid for this digital mic.  That's
> >>> the only point.  Thus, avoiding summing only for known bad devices is
> >>> also a way to go, IMO.  It'd work more or less stably.
> >>> OTOH, muting the right reduces the risk but it also has a problem of
> >>> the lower volume and the lack of right signal in stereo streams, both
> >>> of which aren't easily avoided.
> >>>
> >>> So we need to find some point of compromise...
> >>
> >> Avoiding summing only for known bad devices and only when mixer is set
> >> to capture Internal Mic, is a quite complex condition that would have to
> >> implemented in not only PulseAudio, but every application using ALSA
> >> directly. (Well, and wants to either sum, or to avoid loss of bass and
> >> strange stereo effects.)
> >
> > As mentioned, ALSA-native "default" doesn't sum for mono signals.
> > It's not optimal for stereo, yeah, but better than summing blindly.
> >
> >> The lower volume problem is also an argument only if you want to sum the
> >> signal; so in this case it's lower volume against a cancelled signal
> >> altogether, in which case lower volume is better.
> >
> > Of course.  But my comparison is "pick up only left" vs "sum but
> > right-mute".  In the latter case, the lower volume happens also in
> > stereo streams (as a total volume), too.
> >
> >> That leaves the lack of right signal in stereo streams, as a
> >> disadvantage with the proposed solution. In which use cases do you think
> >> this is a problem?
> >
> > Honestly, I don't know.  It sounds really like a user's preference to
> > me.
> 
> Ok.
> 
> > BTW, it'd be possible to give some offsets to the internal mic capture
> > volume to compensate the lack of a stream.
> 
> Hmm...could you elaborate on this? What type of offsets are you 
> referring to?

cx5051 has separate capture volumes and I thought of adding a base dB
offset (+6dB) only to digital-mic so that it'll be higher than other
inputs.


Takashi

Re: [RFC PATCH] Inverted internal mic

[Eliot Blennerhassett]

David Henningsson <david.henningsson <at> canonical.com> writes:
> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> > At Tue, 28 Feb 2012 14:07:59 +0100,
> > David Henningsson wrote:
> > 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?

Greetings,

Any chance that there has been any progress on this?
I have a machine with dmic and ALC272X (details below) that exhibits this
problem, and can test any proposed patch.

regards

--
Eliot

Machine details:
emachines 350
Codec: Realtek ALC272X
Vendor Id: 0x10ec0272
Subsystem Id: 0x10250349
Revision Id: 0x100001

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> David Henningsson<david.henningsson<at>  canonical.com>  writes:
>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
>>> At Tue, 28 Feb 2012 14:07:59 +0100,
>>> David Henningsson wrote:
>>> 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?
>
> Greetings,
>
> Any chance that there has been any progress on this?
> I have a machine with dmic and ALC272X (details below) that exhibits this
> problem, and can test any proposed patch.

We have a patch in for the Thinkpad U300s, but that one had a Conexant 
codec.
I haven't had time to start working on kernel patches for the Realtek 
ones yet, but meanwhile, I'm tracking known machines here:

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 19 Jun 2012 03:07:40 +0000 (UTC),
Eliot Blennerhassett wrote:
> 
> David Henningsson <david.henningsson <at> canonical.com> writes:
> > On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> > > At Tue, 28 Feb 2012 14:07:59 +0100,
> > > David Henningsson wrote:
> > > 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?
> 
> Greetings,
> 
> Any chance that there has been any progress on this?
> I have a machine with dmic and ALC272X (details below) that exhibits this
> problem, and can test any proposed patch.

Could you give alsa-info.sh output?  This makes debugging a lot
easier.


thanks,

Takashi

> 
> regards
> 
> --
> Eliot
> 
> Machine details:
> emachines 350
> Codec: Realtek ALC272X
> Vendor Id: 0x10ec0272
> Subsystem Id: 0x10250349
> Revision Id: 0x100001
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [RFC PATCH] Inverted internal mic

[Eliot Blennerhassett]

On 20/06/12 20:02, Takashi Iwai wrote:
> Could you give alsa-info.sh output?  This makes debugging a lot
> easier.

upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.61
!!################################

!!Script ran on: Mon Jun 18 01:44:02 UTC 2012


!!Linux Distribution
!!------------------

Ubuntu 12.04 LTS \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu
12.04 LTS"


!!DMI Information
!!---------------

Manufacturer:      eMachines
Product Name:      eM350
Product Version:   V1.06
Firmware Version:  V1.06


!!Kernel Information
!!------------------

Kernel release:    3.2.0-25-generic-pae
Operating System:  GNU/Linux
Architecture:      i686
Processor:         i686
SMP Enabled:       Yes


!!ALSA Version
!!------------

Driver version:     1.0.24
Library version:    1.0.25
Utilities version:  1.0.25


!!Loaded ALSA modules
!!-------------------

snd_hda_intel


!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes

Jack:
      Installed - Yes (/usr/bin/jackd)
      Running - No


!!Soundcards recognised by ALSA
!!-----------------------------

 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0x54200000 irq 44


!!PCI Soundcards installed in the system
!!--------------------------------------

00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition
Audio Controller (rev 02)


!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

00:1b.0 0403: 8086:27d8 (rev 02)
	Subsystem: 1025:0349


!!Modprobe options (Sound related)
!!--------------------------------

snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-usb-audio: index=-2
snd-usb-caiaq: index=-2
snd-usb-ua101: index=-2
snd-usb-us122l: index=-2
snd-usb-usx2y: index=-2
snd-cmipci: mpu_port=0x330 fm_port=0x388
snd-pcsp: index=-2
snd-usb-audio: index=-2


!!Loaded sound module options
!!---------------------------

!!Module: snd_hda_intel
	align_buffer_size : Y
	bdl_pos_adj :
1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	beep_mode : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable_msi : -1
	id :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	index :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	model :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	patch :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	position_fix :
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	power_save : 0
	power_save_controller : Y
	probe_mask :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	probe_only :
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	single_cmd : N
	snoop : Y


!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Realtek ALC272X
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0272
Subsystem Id: 0x10250349
Revision Id: 0x100001
No Modem Function Group found
Default PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=2, o=0, i=0, unsolicited=1, wake=0
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Control: name="Headphone Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Device: name="ALC272X Analog", type="Audio", device=0
  Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
  Amp-Out vals:  [0x40 0x40]
  Converter: stream=8, channel=0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Control: name="Speaker Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
  Amp-Out vals:  [0x40 0x40]
  Converter: stream=8, channel=0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x04 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
  Amp-Out vals:  [0x40 0x40]
  Converter: stream=0, channel=0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x06 [Audio Output] wcaps 0x611: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x8b 0x8b]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x23
Node 0x09 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Control: name="Capture Switch", index=0, device=0
  Control: name="Capture Volume", index=0, device=0
  Device: name="ALC272X Analog", type="Audio", device=0
  Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x90 0x90]
  Converter: stream=4, channel=0
  SDI-Select: 0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x22
Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Control: name="Mic Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Mic Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Beep Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Control: name="Beep Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80
0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 8
     0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16
Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Connection: 2
     0x02 0x0b
Node 0x0d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Connection: 2
     0x03 0x0b
Node 0x0e [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x80 0x80]
  Connection: 2
     0x04 0x0b
Node 0x0f [Audio Mixer] wcaps 0x20010a: Mono Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00] [0x80]
  Connection: 2
     0x02 0x0b
Node 0x10 [Audio Output] wcaps 0x611: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x11 [Pin Complex] wcaps 0x400700: Mono Digital
  Pincap 0x00000010: OUT
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x10
Node 0x12 [Pin Complex] wcaps 0x400401: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x99a30920: [Fixed] Mic at Int ATAPI
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0x2, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x13 [Pin Complex] wcaps 0x400401: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Speaker Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0001003c: IN OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c 0x0d*
Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0001003c: IN OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c* 0x0d
Node 0x16 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x00000034: IN OUT Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x0e
Node 0x17 [Pin Complex] wcaps 0x40050c: Mono Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80]
  Pincap 0x00000010: OUT
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x0f
Node 0x18 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Mic Jack", index=0, device=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x00001734: IN OUT Detect
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x03a19830: [Jack] Mic at Ext Left
    Conn = 1/8, Color = Pink
    DefAssociation = 0x3, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x0e
Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000173c: IN OUT HP Detect
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 3
     0x0c* 0x0d 0x0e
Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x00001734: IN OUT Detect
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x0d
Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000173c: IN OUT HP Detect
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 3
     0x0c* 0x0d 0x0e
Node 0x1c [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x1d [Pin Complex] wcaps 0x400400: Mono
  Pincap 0x00000020: IN
  Pin Default 0x4016892d: [N/A] Speaker at Ext N/A
    Conn = Digital, Color = Purple
    DefAssociation = 0x2, Sequence = 0xd
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x1e [Pin Complex] wcaps 0x400780: Mono Digital
  Pincap 0x00000014: OUT Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x06
Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
  Processing caps: benign=0, ncoeff=17
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Headphone Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0000001c: OUT HP Detect
  Pin Default 0x0321401f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0xf
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 3
     0x0c* 0x0d 0x0e
Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80
0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00]
  Connection: 10
     0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16 0x0b 0x12
Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80
0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 10
     0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16 0x0b 0x13
--endcollapse--


!!ALSA Device nodes
!!-----------------

crw-rw---T+ 1 root audio 116,  5 Jun 18 13:40 /dev/snd/controlC0
crw-rw---T+ 1 root audio 116,  4 Jun 18 13:40 /dev/snd/hwC0D0
crw-rw---T+ 1 root audio 116,  3 Jun 18 13:40 /dev/snd/pcmC0D0c
crw-rw---T+ 1 root audio 116,  2 Jun 18 13:40 /dev/snd/pcmC0D0p
crw-rw---T+ 1 root audio 116,  1 Jun 18 13:40 /dev/snd/seq
crw-rw---T+ 1 root audio 116, 33 Jun 18 13:40 /dev/snd/timer

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root  60 Jun 18 13:40 .
drwxr-xr-x 3 root root 180 Jun 18 13:40 ..
lrwxrwxrwx 1 root root  12 Jun 18 13:40 pci-0000:00:1b.0 -> ../controlC0


!!Aplay/Arecord output
!!--------------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [Intel]

Card hw:0 'Intel'/'HDA Intel at 0x54200000 irq 44'
  Mixer name	: 'Realtek ALC272X'
  Components	: 'HDA:10ec0272,10250349,00100001'
  Controls      : 17
  Simple ctrls  : 9
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Speaker',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
  Capabilities: volume penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 0 [0%] [0.00dB]
  Front Right: 0 [0%] [0.00dB]
Simple mixer control 'Beep',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 16 [52%] [7.50dB] [off]
  Front Right: Capture 16 [52%] [7.50dB] [off]
Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Disabled'


!!Alsactl output
!!--------------

--startcollapse--
state.Intel {
	control.1 {
		iface MIXER
		name 'Headphone Playback Volume'
		value.0 64
		value.1 64
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 64'
			dbmin -6400
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.2 {
		iface MIXER
		name 'Headphone Playback Switch'
		value.0 true
		value.1 true
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.3 {
		iface MIXER
		name 'Speaker Playback Volume'
		value.0 64
		value.1 64
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 64'
			dbmin -6400
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.4 {
		iface MIXER
		name 'Speaker Playback Switch'
		value.0 true
		value.1 true
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.5 {
		iface MIXER
		name 'Mic Playback Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 31'
			dbmin -3450
			dbmax 1200
			dbvalue.0 -3450
			dbvalue.1 -3450
		}
	}
	control.6 {
		iface MIXER
		name 'Mic Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.7 {
		iface MIXER
		name 'Auto-Mute Mode'
		value Disabled
		comment {
			access 'read write'
			type ENUMERATED
			count 1
			item.0 Disabled
			item.1 Enabled
		}
	}
	control.8 {
		iface MIXER
		name 'Mic Boost Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 3'
			dbmin 0
			dbmax 3000
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.9 {
		iface MIXER
		name 'Capture Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.10 {
		iface MIXER
		name 'Capture Volume'
		value.0 16
		value.1 16
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 31'
			dbmin -1650
			dbmax 3000
			dbvalue.0 750
			dbvalue.1 750
		}
	}
	control.11 {
		iface MIXER
		name 'Beep Playback Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 31'
			dbmin -3450
			dbmax 1200
			dbvalue.0 -3450
			dbvalue.1 -3450
		}
	}
	control.12 {
		iface MIXER
		name 'Beep Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.13 {
		iface MIXER
		name 'Master Playback Volume'
		value 64
		comment {
			access 'read write'
			type INTEGER
			count 1
			range '0 - 64'
			dbmin -6400
			dbmax 0
			dbvalue.0 0
		}
	}
	control.14 {
		iface MIXER
		name 'Master Playback Switch'
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.15 {
		iface CARD
		name 'Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.16 {
		iface CARD
		name 'Mic Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.17 {
		iface MIXER
		name 'PCM Playback Volume'
		value.0 255
		value.1 255
		comment {
			access 'read write user'
			type INTEGER
			count 2
			range '0 - 255'
			tlv '0000000100000008ffffec1400000014'
			dbmin -5100
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
}
--endcollapse--


!!All Loaded Modules
!!------------------

Module
dm_crypt
bcma
arc4
joydev
acer_wmi
sparse_keymap
snd_hda_codec_realtek
snd_hda_intel
snd_hda_codec
snd_hwdep
snd_pcm
snd_seq_midi
snd_rawmidi
snd_seq_midi_event
snd_seq
snd_timer
snd_seq_device
brcmsmac
uvcvideo
videodev
psmouse
bnep
serio_raw
rfcomm
snd
bluetooth
mac80211
parport_pc
ppdev
brcmutil
soundcore
cfg80211
crc8
snd_page_alloc
cordic
mac_hid
lp
parport
i915
drm_kms_helper
drm
atl1c
i2c_algo_bit
video
wmi


!!Sysfs Files
!!-----------

/sys/class/sound/hwC0D0/init_pin_configs:
0x11 0x411111f0
0x12 0x99a30920
0x13 0x411111f0
0x14 0x99130110
0x15 0x411111f0
0x16 0x411111f0
0x17 0x411111f0
0x18 0x03a19830
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x4016892d
0x1e 0x411111f0
0x21 0x0321401f

/sys/class/sound/hwC0D0/driver_pin_configs:

/sys/class/sound/hwC0D0/user_pin_configs:

/sys/class/sound/hwC0D0/init_verbs:


!!ALSA/HDA dmesg
!!--------------

[   21.319382] type=1400 audit(1339983621.365:9): apparmor="STATUS"
operation="profile_replace"
name="/usr/lib/connman/scripts/dhclient-script" pid=824
comm="apparmor_parser"
[   21.325408] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 16 (level,
low) -> IRQ 16
[   21.325547] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X
[   21.325617] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[   21.362113] type=1400 audit(1339983621.409:10): apparmor="STATUS"
operation="profile_load"
name="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" pid=823
comm="apparmor_parser"
[   21.433174] type=1400 audit(1339983621.481:11): apparmor="STATUS"
operation="profile_load" name="/usr/lib/telepathy/mission-control-5"
pid=844 comm="apparmor_parser"
[   21.482824] input: HDA Intel Mic as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[   21.495264] input: HDA Intel Headphone as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[   21.524275] atl1c 0000:01:00.0: irq 45 for MSI/MSI-X

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Tue, 19 Jun 2012 09:43:07 +0200,
David Henningsson wrote:
> 
> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> > David Henningsson<david.henningsson<at>  canonical.com>  writes:
> >> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>> David Henningsson wrote:
> >>> 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?
> >
> > Greetings,
> >
> > Any chance that there has been any progress on this?
> > I have a machine with dmic and ALC272X (details below) that exhibits this
> > problem, and can test any proposed patch.
> 
> We have a patch in for the Thinkpad U300s, but that one had a Conexant 
> codec.
> I haven't had time to start working on kernel patches for the Realtek 
> ones yet, but meanwhile, I'm tracking known machines here:
> 
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978

Looking at the codec, it's not so trivial to port the inverted switch
to Realtek.  In the input path of Realtek codecs, there is no
individual capture volume/switch but only a central ADC volume and a
MUX (or a mixer).

I can think of a new boolean switch or an enum to choose whether to
shut off the right channel of the input-mux and the loopback volume.
But it's feasible only if it make sense to PA.


Takashi

Re: [RFC PATCH] Inverted internal mic

[James Courtier-Dutton]

On 28 February 2012 08:57, David Henningsson
<david.henningsson@canonical.com> wrote:
> Hi,
>
> One of the more common problems on laptop machines, is that the internal mic
> provides a stereo signal but with one channel phase inverted, or
> differential output.
>
> This means problems for applications recording two channels but later
> merging them into one, leaving them with zero or near-zero output.
>

If the mic capture looks phase inverted, this might actually be a way
to reduce common mode noise on the pickup.
It might be a differential input for improved dynamic range.
In which case, just dropping one of the channels is not the best,
quality wise, option.
To get the highest quality output, it might be best to do a
differential calculation.
I.e. Channel A - Channel B.
The problem being, if the input is 16bits, the Channel A - Channel B is 17bits.
Can any tests be done to see if Channel A - Channel B has a better S/N
ratio than simply dropping channel B, and copy channel A to channel B?

Kind Regards

James

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> At Tue, 19 Jun 2012 09:43:07 +0200,
> David Henningsson wrote:
>>
>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
>>> David Henningsson<david.henningsson<at>   canonical.com>   writes:
>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
>>>>> David Henningsson wrote:
>>>>> 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?
>>>
>>> Greetings,
>>>
>>> Any chance that there has been any progress on this?
>>> I have a machine with dmic and ALC272X (details below) that exhibits this
>>> problem, and can test any proposed patch.
>>
>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
>> codec.
>> I haven't had time to start working on kernel patches for the Realtek
>> ones yet, but meanwhile, I'm tracking known machines here:
>>
>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
>
> Looking at the codec, it's not so trivial to port the inverted switch
> to Realtek.  In the input path of Realtek codecs, there is no
> individual capture volume/switch but only a central ADC volume and a
> MUX (or a mixer).

Yeah, that's part of why I haven't done it myself yet ;-)

 > I can think of a new boolean switch or an enum to choose whether to
 > shut off the right channel of the input-mux and the loopback volume.
 > But it's feasible only if it make sense to PA.

It seems possible that for ALC269 [1], you could switch path entirely 
(including ADC). I e, the internal mic would go 0x12 -> 0x23 -> 0x08 and 
the external mic would go 0x18 -> 0x24 -> 0x07. That way you could then 
label the volume control on 0x08 "Internal Mic Capture Volume" and 
"Inverted Internal Mic Capture Volume".

Do you think this is a good strategy, or would it lead to other problems 
(i e, what happens when you plug your mic in while actively recording)?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] Example alsa info: 
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/946232/+attachment/3156604/+files/Acer-Aspire-1810TZ__alsa-info.txt

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Wed, 20 Jun 2012 22:53:08 +0100,
James Courtier-Dutton wrote:
> 
> On 28 February 2012 08:57, David Henningsson
> <david.henningsson@canonical.com> wrote:
> > Hi,
> >
> > One of the more common problems on laptop machines, is that the internal mic
> > provides a stereo signal but with one channel phase inverted, or
> > differential output.
> >
> > This means problems for applications recording two channels but later
> > merging them into one, leaving them with zero or near-zero output.
> >
> 
> If the mic capture looks phase inverted, this might actually be a way
> to reduce common mode noise on the pickup.
> It might be a differential input for improved dynamic range.
> In which case, just dropping one of the channels is not the best,
> quality wise, option.
> To get the highest quality output, it might be best to do a
> differential calculation.
> I.e. Channel A - Channel B.

Yes.  And this is just like B is phase inverted in the end.
(So usually divided by 2, too).

The bigger problem is that the change of input sources may happen on
the fly during recording.  And, usually such a PDM source is only the
digital built-in mic.  If you switch to another source, "A - B"
results again in a wrong output.


Takashi

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Thu, 21 Jun 2012 03:15:27 +0200,
David Henningsson wrote:
> 
> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> > At Tue, 19 Jun 2012 09:43:07 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> >>> David Henningsson<david.henningsson<at>   canonical.com>   writes:
> >>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>>>> David Henningsson wrote:
> >>>>> 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?
> >>>
> >>> Greetings,
> >>>
> >>> Any chance that there has been any progress on this?
> >>> I have a machine with dmic and ALC272X (details below) that exhibits this
> >>> problem, and can test any proposed patch.
> >>
> >> We have a patch in for the Thinkpad U300s, but that one had a Conexant
> >> codec.
> >> I haven't had time to start working on kernel patches for the Realtek
> >> ones yet, but meanwhile, I'm tracking known machines here:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
> >
> > Looking at the codec, it's not so trivial to port the inverted switch
> > to Realtek.  In the input path of Realtek codecs, there is no
> > individual capture volume/switch but only a central ADC volume and a
> > MUX (or a mixer).
> 
> Yeah, that's part of why I haven't done it myself yet ;-)
> 
>  > I can think of a new boolean switch or an enum to choose whether to
>  > shut off the right channel of the input-mux and the loopback volume.
>  > But it's feasible only if it make sense to PA.
> 
> It seems possible that for ALC269 [1], you could switch path entirely 
> (including ADC). I e, the internal mic would go 0x12 -> 0x23 -> 0x08 and 
> the external mic would go 0x18 -> 0x24 -> 0x07. That way you could then 
> label the volume control on 0x08 "Internal Mic Capture Volume" and 
> "Inverted Internal Mic Capture Volume".
> 
> Do you think this is a good strategy, or would it lead to other problems 
> (i e, what happens when you plug your mic in while actively recording)?

If the i-mic is the only user for ADC 0x08, this would work.
But when ADC 0x09 has multiple sources like e-mic and line-in,
ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
and this becomes exclusive with "Internal Mic Capture".  It's a bit
confusing, IMO.


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/21/2012 02:52 PM, Takashi Iwai wrote:
> At Thu, 21 Jun 2012 03:15:27 +0200,
> David Henningsson wrote:
>>
>> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
>>> At Tue, 19 Jun 2012 09:43:07 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
>>>>> David Henningsson<david.henningsson<at>    canonical.com>    writes:
>>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
>>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
>>>>>>> David Henningsson wrote:
>>>>>>> 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?
>>>>>
>>>>> Greetings,
>>>>>
>>>>> Any chance that there has been any progress on this?
>>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
>>>>> problem, and can test any proposed patch.
>>>>
>>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
>>>> codec.
>>>> I haven't had time to start working on kernel patches for the Realtek
>>>> ones yet, but meanwhile, I'm tracking known machines here:
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
>>>
>>> Looking at the codec, it's not so trivial to port the inverted switch
>>> to Realtek.  In the input path of Realtek codecs, there is no
>>> individual capture volume/switch but only a central ADC volume and a
>>> MUX (or a mixer).
>>
>> Yeah, that's part of why I haven't done it myself yet ;-)
>>
>>   >  I can think of a new boolean switch or an enum to choose whether to
>>   >  shut off the right channel of the input-mux and the loopback volume.
>>   >  But it's feasible only if it make sense to PA.
>>
>> It seems possible that for ALC269 [1], you could switch path entirely
>> (including ADC). I e, the internal mic would go 0x12 ->  0x23 ->  0x08 and
>> the external mic would go 0x18 ->  0x24 ->  0x07. That way you could then
>> label the volume control on 0x08 "Internal Mic Capture Volume" and
>> "Inverted Internal Mic Capture Volume".
>>
>> Do you think this is a good strategy, or would it lead to other problems
>> (i e, what happens when you plug your mic in while actively recording)?
>
> If the i-mic is the only user for ADC 0x08, this would work.
> But when ADC 0x09 has multiple sources like e-mic and line-in,
> ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
> and this becomes exclusive with "Internal Mic Capture".  It's a bit
> confusing, IMO.

Yes, this logic can only be used when there are two inputs - mic and 
internal mic. That is, the same conditions we today have for determining 
when to have auto-switching on plug/unplug.

Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would 
be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used 
(unless we try to implement some kind of vmaster on the input side, but 
I don't think that would be necessary).

The alsa-info's I've looked at so far all have had one internal mic and 
one external mic on the input side. At least the Realtek ones.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Thu, 21 Jun 2012 15:04:44 +0200,
David Henningsson wrote:
> 
> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
> > At Thu, 21 Jun 2012 03:15:27 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> >>> At Tue, 19 Jun 2012 09:43:07 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> >>>>> David Henningsson<david.henningsson<at>    canonical.com>    writes:
> >>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>>>>>> David Henningsson wrote:
> >>>>>>> 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?
> >>>>>
> >>>>> Greetings,
> >>>>>
> >>>>> Any chance that there has been any progress on this?
> >>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
> >>>>> problem, and can test any proposed patch.
> >>>>
> >>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
> >>>> codec.
> >>>> I haven't had time to start working on kernel patches for the Realtek
> >>>> ones yet, but meanwhile, I'm tracking known machines here:
> >>>>
> >>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
> >>>
> >>> Looking at the codec, it's not so trivial to port the inverted switch
> >>> to Realtek.  In the input path of Realtek codecs, there is no
> >>> individual capture volume/switch but only a central ADC volume and a
> >>> MUX (or a mixer).
> >>
> >> Yeah, that's part of why I haven't done it myself yet ;-)
> >>
> >>   >  I can think of a new boolean switch or an enum to choose whether to
> >>   >  shut off the right channel of the input-mux and the loopback volume.
> >>   >  But it's feasible only if it make sense to PA.
> >>
> >> It seems possible that for ALC269 [1], you could switch path entirely
> >> (including ADC). I e, the internal mic would go 0x12 ->  0x23 ->  0x08 and
> >> the external mic would go 0x18 ->  0x24 ->  0x07. That way you could then
> >> label the volume control on 0x08 "Internal Mic Capture Volume" and
> >> "Inverted Internal Mic Capture Volume".
> >>
> >> Do you think this is a good strategy, or would it lead to other problems
> >> (i e, what happens when you plug your mic in while actively recording)?
> >
> > If the i-mic is the only user for ADC 0x08, this would work.
> > But when ADC 0x09 has multiple sources like e-mic and line-in,
> > ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
> > and this becomes exclusive with "Internal Mic Capture".  It's a bit
> > confusing, IMO.
> 
> Yes, this logic can only be used when there are two inputs - mic and 
> internal mic. That is, the same conditions we today have for determining 
> when to have auto-switching on plug/unplug.
> 
> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would 
> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used 
> (unless we try to implement some kind of vmaster on the input side, but 
> I don't think that would be necessary).
> 
> The alsa-info's I've looked at so far all have had one internal mic and 
> one external mic on the input side. At least the Realtek ones.

Well, it's a bit risky to bet that.  I won't be surprised by any
largish machines with one more jack for supporting 5.1 output and a
digital built-in mic, for example.


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/21/2012 03:19 PM, Takashi Iwai wrote:
> At Thu, 21 Jun 2012 15:04:44 +0200,
> David Henningsson wrote:
>>
>> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
>>> At Thu, 21 Jun 2012 03:15:27 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
>>>>> At Tue, 19 Jun 2012 09:43:07 +0200,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
>>>>>>> David Henningsson<david.henningsson<at>     canonical.com>     writes:
>>>>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
>>>>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
>>>>>>>>> David Henningsson wrote:
>>>>>>>>> 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?
>>>>>>>
>>>>>>> Greetings,
>>>>>>>
>>>>>>> Any chance that there has been any progress on this?
>>>>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
>>>>>>> problem, and can test any proposed patch.
>>>>>>
>>>>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
>>>>>> codec.
>>>>>> I haven't had time to start working on kernel patches for the Realtek
>>>>>> ones yet, but meanwhile, I'm tracking known machines here:
>>>>>>
>>>>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
>>>>>
>>>>> Looking at the codec, it's not so trivial to port the inverted switch
>>>>> to Realtek.  In the input path of Realtek codecs, there is no
>>>>> individual capture volume/switch but only a central ADC volume and a
>>>>> MUX (or a mixer).
>>>>
>>>> Yeah, that's part of why I haven't done it myself yet ;-)
>>>>
>>>>    >   I can think of a new boolean switch or an enum to choose whether to
>>>>    >   shut off the right channel of the input-mux and the loopback volume.
>>>>    >   But it's feasible only if it make sense to PA.
>>>>
>>>> It seems possible that for ALC269 [1], you could switch path entirely
>>>> (including ADC). I e, the internal mic would go 0x12 ->   0x23 ->   0x08 and
>>>> the external mic would go 0x18 ->   0x24 ->   0x07. That way you could then
>>>> label the volume control on 0x08 "Internal Mic Capture Volume" and
>>>> "Inverted Internal Mic Capture Volume".
>>>>
>>>> Do you think this is a good strategy, or would it lead to other problems
>>>> (i e, what happens when you plug your mic in while actively recording)?
>>>
>>> If the i-mic is the only user for ADC 0x08, this would work.
>>> But when ADC 0x09 has multiple sources like e-mic and line-in,
>>> ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
>>> and this becomes exclusive with "Internal Mic Capture".  It's a bit
>>> confusing, IMO.
>>
>> Yes, this logic can only be used when there are two inputs - mic and
>> internal mic. That is, the same conditions we today have for determining
>> when to have auto-switching on plug/unplug.
>>
>> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would
>> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used
>> (unless we try to implement some kind of vmaster on the input side, but
>> I don't think that would be necessary).
>>
>> The alsa-info's I've looked at so far all have had one internal mic and
>> one external mic on the input side. At least the Realtek ones.
>
> Well, it's a bit risky to bet that.  I won't be surprised by any
> largish machines with one more jack for supporting 5.1 output and a
> digital built-in mic, for example.

It is always difficult to bet on the future, but sure, that's a 
drawback. So what were you suggesting instead, in a little more detail?

Maybe making "virtual" volume controls, that would only be affecting the 
node when the actual input is selected?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Thu, 21 Jun 2012 16:23:48 +0200,
David Henningsson wrote:
> 
> On 06/21/2012 03:19 PM, Takashi Iwai wrote:
> > At Thu, 21 Jun 2012 15:04:44 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
> >>> At Thu, 21 Jun 2012 03:15:27 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> >>>>> At Tue, 19 Jun 2012 09:43:07 +0200,
> >>>>> David Henningsson wrote:
> >>>>>>
> >>>>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> >>>>>>> David Henningsson<david.henningsson<at>     canonical.com>     writes:
> >>>>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>>>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>>>>>>>> David Henningsson wrote:
> >>>>>>>>> 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?
> >>>>>>>
> >>>>>>> Greetings,
> >>>>>>>
> >>>>>>> Any chance that there has been any progress on this?
> >>>>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
> >>>>>>> problem, and can test any proposed patch.
> >>>>>>
> >>>>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
> >>>>>> codec.
> >>>>>> I haven't had time to start working on kernel patches for the Realtek
> >>>>>> ones yet, but meanwhile, I'm tracking known machines here:
> >>>>>>
> >>>>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
> >>>>>
> >>>>> Looking at the codec, it's not so trivial to port the inverted switch
> >>>>> to Realtek.  In the input path of Realtek codecs, there is no
> >>>>> individual capture volume/switch but only a central ADC volume and a
> >>>>> MUX (or a mixer).
> >>>>
> >>>> Yeah, that's part of why I haven't done it myself yet ;-)
> >>>>
> >>>>    >   I can think of a new boolean switch or an enum to choose whether to
> >>>>    >   shut off the right channel of the input-mux and the loopback volume.
> >>>>    >   But it's feasible only if it make sense to PA.
> >>>>
> >>>> It seems possible that for ALC269 [1], you could switch path entirely
> >>>> (including ADC). I e, the internal mic would go 0x12 ->   0x23 ->   0x08 and
> >>>> the external mic would go 0x18 ->   0x24 ->   0x07. That way you could then
> >>>> label the volume control on 0x08 "Internal Mic Capture Volume" and
> >>>> "Inverted Internal Mic Capture Volume".
> >>>>
> >>>> Do you think this is a good strategy, or would it lead to other problems
> >>>> (i e, what happens when you plug your mic in while actively recording)?
> >>>
> >>> If the i-mic is the only user for ADC 0x08, this would work.
> >>> But when ADC 0x09 has multiple sources like e-mic and line-in,
> >>> ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
> >>> and this becomes exclusive with "Internal Mic Capture".  It's a bit
> >>> confusing, IMO.
> >>
> >> Yes, this logic can only be used when there are two inputs - mic and
> >> internal mic. That is, the same conditions we today have for determining
> >> when to have auto-switching on plug/unplug.
> >>
> >> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would
> >> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used
> >> (unless we try to implement some kind of vmaster on the input side, but
> >> I don't think that would be necessary).
> >>
> >> The alsa-info's I've looked at so far all have had one internal mic and
> >> one external mic on the input side. At least the Realtek ones.
> >
> > Well, it's a bit risky to bet that.  I won't be surprised by any
> > largish machines with one more jack for supporting 5.1 output and a
> > digital built-in mic, for example.
> 
> It is always difficult to bet on the future, but sure, that's a 
> drawback. So what were you suggesting instead, in a little more detail?

Well, I thought of a mixer switch or enum to specify the inverted mic
right-channel on/off.  If right channel is off, the ADC right channel
mute is set autotmatically when the d-mic is selected as the input
source.

A test patch is below.  It seems working with hda-emu.

(Actually in the case of ALC662 / ALC272x, it could be done in the
 mixer widget; but it's more generic to fiddle with ADC mute.)


Takashi

---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 41475ae..dcc77d0 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -170,6 +170,7 @@ struct alc_spec {
 	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
 	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
 	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
+	hda_nid_t inv_dmic_pin;
 
 	/* hooks */
 	void (*init_hook)(struct hda_codec *codec);
@@ -201,6 +202,8 @@ struct alc_spec {
 	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
 	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
 	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
+	unsigned int inv_dmic_fixup:1;
+	unsigned int inv_dmic_enabled:1;
 
 	/* auto-mute control */
 	int automute_mode;
@@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
 }
 
 static void call_update_outputs(struct hda_codec *codec);
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
 
 /* select the given imux item; either unmute exclusively or select the route */
 static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
@@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
 					  AC_VERB_SET_CONNECT_SEL,
 					  imux->items[idx].index);
 	}
+	alc_inv_dmic_sync(codec, true);
 	return 1;
 }
 
@@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
 
 static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
 				 struct snd_ctl_elem_value *ucontrol,
-				 getput_call_t func, bool check_adc_switch)
+				 getput_call_t func, bool is_put)
 {
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
 	int i, err = 0;
 
 	mutex_lock(&codec->control_mutex);
-	if (check_adc_switch && spec->dyn_adc_switch) {
+	if (is_put && spec->dyn_adc_switch) {
 		for (i = 0; i < spec->num_adc_nids; i++) {
 			kcontrol->private_value =
 				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],
@@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
 						    3, 0, HDA_INPUT);
 		err = func(kcontrol, ucontrol);
 	}
+	if (err >= 0 && is_put)
+		alc_inv_dmic_sync(codec, false);
  error:
 	mutex_unlock(&codec->control_mutex);
 	return err;
@@ -1676,6 +1683,93 @@ DEFINE_CAPMIX_NOSRC(2);
 DEFINE_CAPMIX_NOSRC(3);
 
 /*
+ * Inverted digital-mic handling
+ */
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
+{
+	struct alc_spec *spec = codec->spec;
+	int i;
+
+	if (!spec->inv_dmic_fixup)
+		return;
+	if (spec->inv_dmic_enabled && !force)
+		return;
+	for (i = 0; i < spec->num_adc_nids; i++) {
+		int src = spec->dyn_adc_switch ? 0 : i;
+		bool dmic_fixup = false;
+		hda_nid_t nid;
+		int parm, dir, v;
+
+		if (!spec->inv_dmic_enabled &&
+		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
+			dmic_fixup = true;
+		if (!dmic_fixup && !force)
+			continue;
+		if (spec->vol_in_capsrc) {
+			nid = spec->capsrc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
+			dir = HDA_OUTPUT;
+		} else {
+			nid = spec->adc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT;
+			dir = HDA_INPUT;
+		}
+		v = snd_hda_codec_amp_read(codec, nid, 1, dir, 0);
+		if (v & 0x80) /* if already muted, we don't need to touch */
+			continue;
+		if (dmic_fixup) /* mute for d-mic required */
+			v |= 0x80;
+		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
+				    parm | v);
+	}
+}
+
+static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	
+	ucontrol->value.integer.value[0] = spec->inv_dmic_enabled;
+	return 0;
+}
+
+static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	unsigned int val = !!ucontrol->value.integer.value[0];
+
+	if (val == spec->inv_dmic_enabled)
+		return 0;
+	spec->inv_dmic_enabled = val;
+	alc_inv_dmic_sync(codec, true);
+	return 0;
+}
+
+static const struct snd_kcontrol_new alc_inv_dmic_sw = {
+	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+	.info = snd_ctl_boolean_mono_info,
+	.get = alc_inv_dmic_sw_get,
+	.put = alc_inv_dmic_sw_put,
+};
+
+static int alc_add_inv_dmic_mixer(struct hda_codec *codec, hda_nid_t nid)
+{
+	struct alc_spec *spec = codec->spec;
+	struct snd_kcontrol_new *knew = alc_kcontrol_new(spec);
+	if (!knew)
+		return -ENOMEM;
+	*knew = alc_inv_dmic_sw;
+	knew->name = kstrdup("Inverted Mic Capture Switch", GFP_KERNEL);
+	spec->inv_dmic_fixup = 1;
+	spec->inv_dmic_enabled = 1;
+	spec->inv_dmic_pin = nid;
+	return 0;
+}
+
+/*
  * virtual master controls
  */
 
@@ -2316,6 +2410,7 @@ static int alc_resume(struct hda_codec *codec)
 	codec->patch_ops.init(codec);
 	snd_hda_codec_resume_amp(codec);
 	snd_hda_codec_resume_cache(codec);
+	alc_inv_dmic_sync(codec, true);
 	hda_call_check_power_status(codec, 0x01);
 	return 0;
 }
@@ -6424,6 +6519,13 @@ static void alc272_fixup_mario(struct hda_codec *codec,
 		       "hda_codec: failed to override amp caps for NID 0x2\n");
 }
 
+static void alc662_fixup_inv_dmic(struct hda_codec *codec,
+				  const struct alc_fixup *fix, int action)
+{
+	if (action == ALC_FIXUP_ACT_PROBE)
+		alc_add_inv_dmic_mixer(codec, 0x12);
+}
+
 enum {
 	ALC662_FIXUP_ASPIRE,
 	ALC662_FIXUP_IDEAPAD,
@@ -6441,6 +6543,7 @@ enum {
 	ALC662_FIXUP_ASUS_MODE8,
 	ALC662_FIXUP_NO_JACK_DETECT,
 	ALC662_FIXUP_ZOTAC_Z68,
+	ALC662_FIXUP_INV_DMIC,
 };
 
 static const struct alc_fixup alc662_fixups[] = {
@@ -6597,12 +6700,17 @@ static const struct alc_fixup alc662_fixups[] = {
 			{ }
 		}
 	},
+	[ALC662_FIXUP_INV_DMIC] = {
+		.type = ALC_FIXUP_FUNC,
+		.v.func = alc662_fixup_inv_dmic,
+	},
 };
 
 static const struct snd_pci_quirk alc662_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
 	SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
 	SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
+	SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x1025, 0x038b, "Acer Aspire 8943G", ALC662_FIXUP_ASPIRE),
 	SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
 	SND_PCI_QUIRK(0x1043, 0x8469, "ASUS mobo", ALC662_FIXUP_NO_JACK_DETECT),

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/22/2012 11:33 AM, Takashi Iwai wrote:
> At Thu, 21 Jun 2012 16:23:48 +0200,
> David Henningsson wrote:
>>
>> On 06/21/2012 03:19 PM, Takashi Iwai wrote:
>>> At Thu, 21 Jun 2012 15:04:44 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
>>>>> At Thu, 21 Jun 2012 03:15:27 +0200,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
>>>>>>> At Tue, 19 Jun 2012 09:43:07 +0200,
>>>>>>> David Henningsson wrote:
>>>>>>>>
>>>>>>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
>>>>>>>>> David Henningsson<david.henningsson<at>      canonical.com>      writes:
>>>>>>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
>>>>>>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
>>>>>>>>>>> David Henningsson wrote:
>>>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> Any chance that there has been any progress on this?
>>>>>>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
>>>>>>>>> problem, and can test any proposed patch.
>>>>>>>>
>>>>>>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
>>>>>>>> codec.
>>>>>>>> I haven't had time to start working on kernel patches for the Realtek
>>>>>>>> ones yet, but meanwhile, I'm tracking known machines here:
>>>>>>>>
>>>>>>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
>>>>>>>
>>>>>>> Looking at the codec, it's not so trivial to port the inverted switch
>>>>>>> to Realtek.  In the input path of Realtek codecs, there is no
>>>>>>> individual capture volume/switch but only a central ADC volume and a
>>>>>>> MUX (or a mixer).
>>>>>>
>>>>>> Yeah, that's part of why I haven't done it myself yet ;-)
>>>>>>
>>>>>>     >    I can think of a new boolean switch or an enum to choose whether to
>>>>>>     >    shut off the right channel of the input-mux and the loopback volume.
>>>>>>     >    But it's feasible only if it make sense to PA.
>>>>>>
>>>>>> It seems possible that for ALC269 [1], you could switch path entirely
>>>>>> (including ADC). I e, the internal mic would go 0x12 ->    0x23 ->    0x08 and
>>>>>> the external mic would go 0x18 ->    0x24 ->    0x07. That way you could then
>>>>>> label the volume control on 0x08 "Internal Mic Capture Volume" and
>>>>>> "Inverted Internal Mic Capture Volume".
>>>>>>
>>>>>> Do you think this is a good strategy, or would it lead to other problems
>>>>>> (i e, what happens when you plug your mic in while actively recording)?
>>>>>
>>>>> If the i-mic is the only user for ADC 0x08, this would work.
>>>>> But when ADC 0x09 has multiple sources like e-mic and line-in,
>>>>> ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
>>>>> and this becomes exclusive with "Internal Mic Capture".  It's a bit
>>>>> confusing, IMO.
>>>>
>>>> Yes, this logic can only be used when there are two inputs - mic and
>>>> internal mic. That is, the same conditions we today have for determining
>>>> when to have auto-switching on plug/unplug.
>>>>
>>>> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would
>>>> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used
>>>> (unless we try to implement some kind of vmaster on the input side, but
>>>> I don't think that would be necessary).
>>>>
>>>> The alsa-info's I've looked at so far all have had one internal mic and
>>>> one external mic on the input side. At least the Realtek ones.
>>>
>>> Well, it's a bit risky to bet that.  I won't be surprised by any
>>> largish machines with one more jack for supporting 5.1 output and a
>>> digital built-in mic, for example.
>>
>> It is always difficult to bet on the future, but sure, that's a
>> drawback. So what were you suggesting instead, in a little more detail?
>
> Well, I thought of a mixer switch or enum to specify the inverted mic
> right-channel on/off.  If right channel is off, the ADC right channel
> mute is set autotmatically when the d-mic is selected as the input
> source.

Ok. I think this approach is okay.

>
> A test patch is below.  It seems working with hda-emu.

Thanks for the patch. I haven't tested it, but just read it through, see 
comments below.

>
> (Actually in the case of ALC662 / ALC272x, it could be done in the
>   mixer widget; but it's more generic to fiddle with ADC mute.)
>
>
> Takashi
>
> ---
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 41475ae..dcc77d0 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -170,6 +170,7 @@ struct alc_spec {
>   	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
>   	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
>   	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
> +	hda_nid_t inv_dmic_pin;
>
>   	/* hooks */
>   	void (*init_hook)(struct hda_codec *codec);
> @@ -201,6 +202,8 @@ struct alc_spec {
>   	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
>   	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
>   	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
> +	unsigned int inv_dmic_fixup:1;
> +	unsigned int inv_dmic_enabled:1;
>
>   	/* auto-mute control */
>   	int automute_mode;
> @@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
>   }
>
>   static void call_update_outputs(struct hda_codec *codec);
> +static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
>
>   /* select the given imux item; either unmute exclusively or select the route */
>   static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
> @@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
>   					  AC_VERB_SET_CONNECT_SEL,
>   					  imux->items[idx].index);
>   	}
> +	alc_inv_dmic_sync(codec, true);
>   	return 1;
>   }
>
> @@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
>
>   static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
>   				 struct snd_ctl_elem_value *ucontrol,
> -				 getput_call_t func, bool check_adc_switch)
> +				 getput_call_t func, bool is_put)
>   {
>   	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
>   	struct alc_spec *spec = codec->spec;
>   	int i, err = 0;
>
>   	mutex_lock(&codec->control_mutex);
> -	if (check_adc_switch&&  spec->dyn_adc_switch) {
> +	if (is_put&&  spec->dyn_adc_switch) {
>   		for (i = 0; i<  spec->num_adc_nids; i++) {
>   			kcontrol->private_value =
>   				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],
> @@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
>   						    3, 0, HDA_INPUT);
>   		err = func(kcontrol, ucontrol);
>   	}
> +	if (err>= 0&&  is_put)
> +		alc_inv_dmic_sync(codec, false);
>    error:
>   	mutex_unlock(&codec->control_mutex);
>   	return err;
> @@ -1676,6 +1683,93 @@ DEFINE_CAPMIX_NOSRC(2);
>   DEFINE_CAPMIX_NOSRC(3);
>
>   /*
> + * Inverted digital-mic handling
> + */
> +static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
> +{
> +	struct alc_spec *spec = codec->spec;
> +	int i;
> +
> +	if (!spec->inv_dmic_fixup)
> +		return;
> +	if (spec->inv_dmic_enabled&&  !force)
> +		return;
> +	for (i = 0; i<  spec->num_adc_nids; i++) {
> +		int src = spec->dyn_adc_switch ? 0 : i;
> +		bool dmic_fixup = false;
> +		hda_nid_t nid;
> +		int parm, dir, v;
> +
> +		if (!spec->inv_dmic_enabled&&
> +		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
> +			dmic_fixup = true;
> +		if (!dmic_fixup&&  !force)
> +			continue;
> +		if (spec->vol_in_capsrc) {
> +			nid = spec->capsrc_nids[i];
> +			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
> +			dir = HDA_OUTPUT;
> +		} else {
> +			nid = spec->adc_nids[i];
> +			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT;
> +			dir = HDA_INPUT;
> +		}
> +		v = snd_hda_codec_amp_read(codec, nid, 1, dir, 0);
> +		if (v&  0x80) /* if already muted, we don't need to touch */
> +			continue;
> +		if (dmic_fixup) /* mute for d-mic required */
> +			v |= 0x80;

This seems strange. Won't you need to manually unmute in some cases (if 
the "Inverted Capture" is manually turned on, or external mic is inserted)?

Maybe you mean like this:

new_value = dmic_fixup ? (v | 0x80) : (v & ~0x80);
if (new_value == v)
	continue;

But then, what if you turn "Inverted Capture" on while "Capture Switch" 
is off...?

> +		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
> +				    parm | v);
> +	}
> +}
> +
> +static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
> +			       struct snd_ctl_elem_value *ucontrol)
> +{
> +	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
> +	struct alc_spec *spec = codec->spec;
> +	
> +	ucontrol->value.integer.value[0] = spec->inv_dmic_enabled;
> +	return 0;
> +}
> +
> +static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
> +			       struct snd_ctl_elem_value *ucontrol)
> +{
> +	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
> +	struct alc_spec *spec = codec->spec;
> +	unsigned int val = !!ucontrol->value.integer.value[0];
> +
> +	if (val == spec->inv_dmic_enabled)
> +		return 0;
> +	spec->inv_dmic_enabled = val;
> +	alc_inv_dmic_sync(codec, true);
> +	return 0;
> +}
> +
> +static const struct snd_kcontrol_new alc_inv_dmic_sw = {
> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> +	.info = snd_ctl_boolean_mono_info,
> +	.get = alc_inv_dmic_sw_get,
> +	.put = alc_inv_dmic_sw_put,
> +};
> +
> +static int alc_add_inv_dmic_mixer(struct hda_codec *codec, hda_nid_t nid)
> +{
> +	struct alc_spec *spec = codec->spec;
> +	struct snd_kcontrol_new *knew = alc_kcontrol_new(spec);
> +	if (!knew)
> +		return -ENOMEM;
> +	*knew = alc_inv_dmic_sw;
> +	knew->name = kstrdup("Inverted Mic Capture Switch", GFP_KERNEL);

It should be "Inverted Internal Mic Capture Switch" (missing word 
"Internal").

> +	spec->inv_dmic_fixup = 1;
> +	spec->inv_dmic_enabled = 1;
> +	spec->inv_dmic_pin = nid;
> +	return 0;
> +}
> +
> +/*
>    * virtual master controls
>    */
>
> @@ -2316,6 +2410,7 @@ static int alc_resume(struct hda_codec *codec)
>   	codec->patch_ops.init(codec);
>   	snd_hda_codec_resume_amp(codec);
>   	snd_hda_codec_resume_cache(codec);
> +	alc_inv_dmic_sync(codec, true);
>   	hda_call_check_power_status(codec, 0x01);
>   	return 0;
>   }
> @@ -6424,6 +6519,13 @@ static void alc272_fixup_mario(struct hda_codec *codec,
>   		       "hda_codec: failed to override amp caps for NID 0x2\n");
>   }
>
> +static void alc662_fixup_inv_dmic(struct hda_codec *codec,
> +				  const struct alc_fixup *fix, int action)
> +{
> +	if (action == ALC_FIXUP_ACT_PROBE)
> +		alc_add_inv_dmic_mixer(codec, 0x12);
> +}
> +
>   enum {
>   	ALC662_FIXUP_ASPIRE,
>   	ALC662_FIXUP_IDEAPAD,
> @@ -6441,6 +6543,7 @@ enum {
>   	ALC662_FIXUP_ASUS_MODE8,
>   	ALC662_FIXUP_NO_JACK_DETECT,
>   	ALC662_FIXUP_ZOTAC_Z68,
> +	ALC662_FIXUP_INV_DMIC,
>   };
>
>   static const struct alc_fixup alc662_fixups[] = {
> @@ -6597,12 +6700,17 @@ static const struct alc_fixup alc662_fixups[] = {
>   			{ }
>   		}
>   	},
> +	[ALC662_FIXUP_INV_DMIC] = {
> +		.type = ALC_FIXUP_FUNC,
> +		.v.func = alc662_fixup_inv_dmic,
> +	},
>   };
>
>   static const struct snd_pci_quirk alc662_fixup_tbl[] = {
>   	SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
>   	SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
>   	SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
> +	SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
>   	SND_PCI_QUIRK(0x1025, 0x038b, "Acer Aspire 8943G", ALC662_FIXUP_ASPIRE),
>   	SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
>   	SND_PCI_QUIRK(0x1043, 0x8469, "ASUS mobo", ALC662_FIXUP_NO_JACK_DETECT),
>



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Fri, 22 Jun 2012 12:46:55 +0200,
David Henningsson wrote:
> 
> On 06/22/2012 11:33 AM, Takashi Iwai wrote:
> > At Thu, 21 Jun 2012 16:23:48 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/21/2012 03:19 PM, Takashi Iwai wrote:
> >>> At Thu, 21 Jun 2012 15:04:44 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
> >>>>> At Thu, 21 Jun 2012 03:15:27 +0200,
> >>>>> David Henningsson wrote:
> >>>>>>
> >>>>>> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> >>>>>>> At Tue, 19 Jun 2012 09:43:07 +0200,
> >>>>>>> David Henningsson wrote:
> >>>>>>>>
> >>>>>>>> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> >>>>>>>>> David Henningsson<david.henningsson<at>      canonical.com>      writes:
> >>>>>>>>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>>>>>>>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>>>>>>>>>> David Henningsson wrote:
> >>>>>>>>>>> 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?
> >>>>>>>>>
> >>>>>>>>> Greetings,
> >>>>>>>>>
> >>>>>>>>> Any chance that there has been any progress on this?
> >>>>>>>>> I have a machine with dmic and ALC272X (details below) that exhibits this
> >>>>>>>>> problem, and can test any proposed patch.
> >>>>>>>>
> >>>>>>>> We have a patch in for the Thinkpad U300s, but that one had a Conexant
> >>>>>>>> codec.
> >>>>>>>> I haven't had time to start working on kernel patches for the Realtek
> >>>>>>>> ones yet, but meanwhile, I'm tracking known machines here:
> >>>>>>>>
> >>>>>>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
> >>>>>>>
> >>>>>>> Looking at the codec, it's not so trivial to port the inverted switch
> >>>>>>> to Realtek.  In the input path of Realtek codecs, there is no
> >>>>>>> individual capture volume/switch but only a central ADC volume and a
> >>>>>>> MUX (or a mixer).
> >>>>>>
> >>>>>> Yeah, that's part of why I haven't done it myself yet ;-)
> >>>>>>
> >>>>>>     >    I can think of a new boolean switch or an enum to choose whether to
> >>>>>>     >    shut off the right channel of the input-mux and the loopback volume.
> >>>>>>     >    But it's feasible only if it make sense to PA.
> >>>>>>
> >>>>>> It seems possible that for ALC269 [1], you could switch path entirely
> >>>>>> (including ADC). I e, the internal mic would go 0x12 ->    0x23 ->    0x08 and
> >>>>>> the external mic would go 0x18 ->    0x24 ->    0x07. That way you could then
> >>>>>> label the volume control on 0x08 "Internal Mic Capture Volume" and
> >>>>>> "Inverted Internal Mic Capture Volume".
> >>>>>>
> >>>>>> Do you think this is a good strategy, or would it lead to other problems
> >>>>>> (i e, what happens when you plug your mic in while actively recording)?
> >>>>>
> >>>>> If the i-mic is the only user for ADC 0x08, this would work.
> >>>>> But when ADC 0x09 has multiple sources like e-mic and line-in,
> >>>>> ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
> >>>>> and this becomes exclusive with "Internal Mic Capture".  It's a bit
> >>>>> confusing, IMO.
> >>>>
> >>>> Yes, this logic can only be used when there are two inputs - mic and
> >>>> internal mic. That is, the same conditions we today have for determining
> >>>> when to have auto-switching on plug/unplug.
> >>>>
> >>>> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would
> >>>> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used
> >>>> (unless we try to implement some kind of vmaster on the input side, but
> >>>> I don't think that would be necessary).
> >>>>
> >>>> The alsa-info's I've looked at so far all have had one internal mic and
> >>>> one external mic on the input side. At least the Realtek ones.
> >>>
> >>> Well, it's a bit risky to bet that.  I won't be surprised by any
> >>> largish machines with one more jack for supporting 5.1 output and a
> >>> digital built-in mic, for example.
> >>
> >> It is always difficult to bet on the future, but sure, that's a
> >> drawback. So what were you suggesting instead, in a little more detail?
> >
> > Well, I thought of a mixer switch or enum to specify the inverted mic
> > right-channel on/off.  If right channel is off, the ADC right channel
> > mute is set autotmatically when the d-mic is selected as the input
> > source.
> 
> Ok. I think this approach is okay.
> 
> >
> > A test patch is below.  It seems working with hda-emu.
> 
> Thanks for the patch. I haven't tested it, but just read it through, see 
> comments below.
> 
> >
> > (Actually in the case of ALC662 / ALC272x, it could be done in the
> >   mixer widget; but it's more generic to fiddle with ADC mute.)
> >
> >
> > Takashi
> >
> > ---
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 41475ae..dcc77d0 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -170,6 +170,7 @@ struct alc_spec {
> >   	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
> >   	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
> >   	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
> > +	hda_nid_t inv_dmic_pin;
> >
> >   	/* hooks */
> >   	void (*init_hook)(struct hda_codec *codec);
> > @@ -201,6 +202,8 @@ struct alc_spec {
> >   	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
> >   	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
> >   	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
> > +	unsigned int inv_dmic_fixup:1;
> > +	unsigned int inv_dmic_enabled:1;
> >
> >   	/* auto-mute control */
> >   	int automute_mode;
> > @@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
> >   }
> >
> >   static void call_update_outputs(struct hda_codec *codec);
> > +static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
> >
> >   /* select the given imux item; either unmute exclusively or select the route */
> >   static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
> > @@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
> >   					  AC_VERB_SET_CONNECT_SEL,
> >   					  imux->items[idx].index);
> >   	}
> > +	alc_inv_dmic_sync(codec, true);
> >   	return 1;
> >   }
> >
> > @@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
> >
> >   static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
> >   				 struct snd_ctl_elem_value *ucontrol,
> > -				 getput_call_t func, bool check_adc_switch)
> > +				 getput_call_t func, bool is_put)
> >   {
> >   	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
> >   	struct alc_spec *spec = codec->spec;
> >   	int i, err = 0;
> >
> >   	mutex_lock(&codec->control_mutex);
> > -	if (check_adc_switch&&  spec->dyn_adc_switch) {
> > +	if (is_put&&  spec->dyn_adc_switch) {
> >   		for (i = 0; i<  spec->num_adc_nids; i++) {
> >   			kcontrol->private_value =
> >   				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],
> > @@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
> >   						    3, 0, HDA_INPUT);
> >   		err = func(kcontrol, ucontrol);
> >   	}
> > +	if (err>= 0&&  is_put)
> > +		alc_inv_dmic_sync(codec, false);
> >    error:
> >   	mutex_unlock(&codec->control_mutex);
> >   	return err;
> > @@ -1676,6 +1683,93 @@ DEFINE_CAPMIX_NOSRC(2);
> >   DEFINE_CAPMIX_NOSRC(3);
> >
> >   /*
> > + * Inverted digital-mic handling
> > + */
> > +static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
> > +{
> > +	struct alc_spec *spec = codec->spec;
> > +	int i;
> > +
> > +	if (!spec->inv_dmic_fixup)
> > +		return;
> > +	if (spec->inv_dmic_enabled&&  !force)
> > +		return;
> > +	for (i = 0; i<  spec->num_adc_nids; i++) {
> > +		int src = spec->dyn_adc_switch ? 0 : i;
> > +		bool dmic_fixup = false;
> > +		hda_nid_t nid;
> > +		int parm, dir, v;
> > +
> > +		if (!spec->inv_dmic_enabled&&
> > +		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
> > +			dmic_fixup = true;
> > +		if (!dmic_fixup&&  !force)
> > +			continue;
> > +		if (spec->vol_in_capsrc) {
> > +			nid = spec->capsrc_nids[i];
> > +			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
> > +			dir = HDA_OUTPUT;
> > +		} else {
> > +			nid = spec->adc_nids[i];
> > +			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT;
> > +			dir = HDA_INPUT;
> > +		}
> > +		v = snd_hda_codec_amp_read(codec, nid, 1, dir, 0);
> > +		if (v&  0x80) /* if already muted, we don't need to touch */
> > +			continue;
> > +		if (dmic_fixup) /* mute for d-mic required */
> > +			v |= 0x80;
> 
> This seems strange. Won't you need to manually unmute in some cases (if 
> the "Inverted Capture" is manually turned on, or external mic is inserted)?

Yes, it'll be restored.  The check "if (v & 0x80)" is only an
optimization.

> 
> Maybe you mean like this:
> 
> new_value = dmic_fixup ? (v | 0x80) : (v & ~0x80);
> if (new_value == v)
> 	continue;

No, this function does only either adding the artificial R-ch mute
(when dmix_fiup=1) or restoring the cached value (dmix_fixup=0).
And the actual value isn't the value returned from
snd_hda_codec_amp_read().

OK, the code is a bit tricky -- I try to explain more.
alc_inv_dmic_sync() is called always after some action has been done
for ADC amp.  Then it checks whether the current input source is d-mic
and the fix is needed.  If yes, it executes the amp verb with the mute
bit, but _without caching_.  In that way, the original values of the
capture vol/switch are kept there.

When the fix is disabled, the cached values are restored.  It's called
with force=true.

> But then, what if you turn "Inverted Capture" on while "Capture Switch" 
> is off...?

It works because the mute bit is _added_.


> > +		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
> > +				    parm | v);
> > +	}
> > +}
> > +
> > +static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
> > +			       struct snd_ctl_elem_value *ucontrol)
> > +{
> > +	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
> > +	struct alc_spec *spec = codec->spec;
> > +	
> > +	ucontrol->value.integer.value[0] = spec->inv_dmic_enabled;
> > +	return 0;
> > +}
> > +
> > +static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
> > +			       struct snd_ctl_elem_value *ucontrol)
> > +{
> > +	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
> > +	struct alc_spec *spec = codec->spec;
> > +	unsigned int val = !!ucontrol->value.integer.value[0];
> > +
> > +	if (val == spec->inv_dmic_enabled)
> > +		return 0;
> > +	spec->inv_dmic_enabled = val;
> > +	alc_inv_dmic_sync(codec, true);
> > +	return 0;
> > +}
> > +
> > +static const struct snd_kcontrol_new alc_inv_dmic_sw = {
> > +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> > +	.info = snd_ctl_boolean_mono_info,
> > +	.get = alc_inv_dmic_sw_get,
> > +	.put = alc_inv_dmic_sw_put,
> > +};
> > +
> > +static int alc_add_inv_dmic_mixer(struct hda_codec *codec, hda_nid_t nid)
> > +{
> > +	struct alc_spec *spec = codec->spec;
> > +	struct snd_kcontrol_new *knew = alc_kcontrol_new(spec);
> > +	if (!knew)
> > +		return -ENOMEM;
> > +	*knew = alc_inv_dmic_sw;
> > +	knew->name = kstrdup("Inverted Mic Capture Switch", GFP_KERNEL);
> 
> It should be "Inverted Internal Mic Capture Switch" (missing word 
> "Internal").

OK, will change.


Takashi

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

OK, below is the respin with more comments.
Eliot, could you check whether the patch works?


thanks,

Takashi

---
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda - Add the inverted digital mic workaround to Realtek codecs

Some laptops are equipped with ForteMedia digital mics that give the
differential input.  With such devices, summing stereo streams into a
mono (like PulseAudio does) results in almost silence.

This patch provides a workaround for this bug by adding a new mixer
switch to turn on/off the right channel of digital mic, just like a
similar fix for Conexant codecs.

When the new switch "Inverted Internal Mic Capture Switch" is off and
the current input source is the digital mic, the right channel of the
recording stream is muted.  When another input source is selected, the
right channel is restored.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/patch_realtek.c |  127 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 125 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f8f4906..5c2270b 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -170,6 +170,7 @@ struct alc_spec {
 	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
 	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
 	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
+	hda_nid_t inv_dmic_pin;
 
 	/* hooks */
 	void (*init_hook)(struct hda_codec *codec);
@@ -201,6 +202,8 @@ struct alc_spec {
 	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
 	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
 	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
+	unsigned int inv_dmic_fixup:1; /* has inverted digital-mic workaround */
+	unsigned int inv_dmic_muted:1; /* R-ch of inv d-mic is muted? */
 
 	/* auto-mute control */
 	int automute_mode;
@@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
 }
 
 static void call_update_outputs(struct hda_codec *codec);
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
 
 /* select the given imux item; either unmute exclusively or select the route */
 static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
@@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
 					  AC_VERB_SET_CONNECT_SEL,
 					  imux->items[idx].index);
 	}
+	alc_inv_dmic_sync(codec, true);
 	return 1;
 }
 
@@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
 
 static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
 				 struct snd_ctl_elem_value *ucontrol,
-				 getput_call_t func, bool check_adc_switch)
+				 getput_call_t func, bool is_put)
 {
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
 	int i, err = 0;
 
 	mutex_lock(&codec->control_mutex);
-	if (check_adc_switch && spec->dyn_adc_switch) {
+	if (is_put && spec->dyn_adc_switch) {
 		for (i = 0; i < spec->num_adc_nids; i++) {
 			kcontrol->private_value =
 				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],
@@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
 						    3, 0, HDA_INPUT);
 		err = func(kcontrol, ucontrol);
 	}
+	if (err >= 0 && is_put)
+		alc_inv_dmic_sync(codec, false);
  error:
 	mutex_unlock(&codec->control_mutex);
 	return err;
@@ -1676,6 +1683,108 @@ DEFINE_CAPMIX_NOSRC(2);
 DEFINE_CAPMIX_NOSRC(3);
 
 /*
+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream.  This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)
+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.
+ */
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
+{
+	struct alc_spec *spec = codec->spec;
+	int i;
+
+	if (!spec->inv_dmic_fixup)
+		return;
+	if (!spec->inv_dmic_muted && !force)
+		return;
+	for (i = 0; i < spec->num_adc_nids; i++) {
+		int src = spec->dyn_adc_switch ? 0 : i;
+		bool dmic_fixup = false;
+		hda_nid_t nid;
+		int parm, dir, v;
+
+		if (spec->inv_dmic_muted &&
+		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
+			dmic_fixup = true;
+		if (!dmic_fixup && !force)
+			continue;
+		if (spec->vol_in_capsrc) {
+			nid = spec->capsrc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
+			dir = HDA_OUTPUT;
+		} else {
+			nid = spec->adc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT;
+			dir = HDA_INPUT;
+		}
+		/* we care only right channel */
+		v = snd_hda_codec_amp_read(codec, nid, 1, dir, 0);
+		if (v & 0x80) /* if already muted, we don't need to touch */
+			continue;
+		if (dmic_fixup) /* add mute for d-mic */
+			v |= 0x80;
+		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
+				    parm | v);
+	}
+}
+
+static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+
+	ucontrol->value.integer.value[0] = !spec->inv_dmic_muted;
+	return 0;
+}
+
+static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	unsigned int val = !ucontrol->value.integer.value[0];
+
+	if (val == spec->inv_dmic_muted)
+		return 0;
+	spec->inv_dmic_muted = val;
+	alc_inv_dmic_sync(codec, true);
+	return 0;
+}
+
+static const struct snd_kcontrol_new alc_inv_dmic_sw = {
+	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+	.info = snd_ctl_boolean_mono_info,
+	.get = alc_inv_dmic_sw_get,
+	.put = alc_inv_dmic_sw_put,
+};
+
+static int alc_add_inv_dmic_mixer(struct hda_codec *codec, hda_nid_t nid)
+{
+	struct alc_spec *spec = codec->spec;
+	struct snd_kcontrol_new *knew = alc_kcontrol_new(spec);
+	if (!knew)
+		return -ENOMEM;
+	*knew = alc_inv_dmic_sw;
+	knew->name = kstrdup("Inverted Internal Mic Capture Switch", GFP_KERNEL);
+	if (!knew->name)
+		return -ENOMEM;
+	spec->inv_dmic_fixup = 1;
+	spec->inv_dmic_muted = 0;
+	spec->inv_dmic_pin = nid;
+	return 0;
+}
+
+/*
  * virtual master controls
  */
 
@@ -2316,6 +2425,7 @@ static int alc_resume(struct hda_codec *codec)
 	codec->patch_ops.init(codec);
 	snd_hda_codec_resume_amp(codec);
 	snd_hda_codec_resume_cache(codec);
+	alc_inv_dmic_sync(codec, true);
 	hda_call_check_power_status(codec, 0x01);
 	return 0;
 }
@@ -6424,6 +6534,13 @@ static void alc272_fixup_mario(struct hda_codec *codec,
 		       "hda_codec: failed to override amp caps for NID 0x2\n");
 }
 
+static void alc662_fixup_inv_dmic(struct hda_codec *codec,
+				  const struct alc_fixup *fix, int action)
+{
+	if (action == ALC_FIXUP_ACT_PROBE)
+		alc_add_inv_dmic_mixer(codec, 0x12);
+}
+
 enum {
 	ALC662_FIXUP_ASPIRE,
 	ALC662_FIXUP_IDEAPAD,
@@ -6441,6 +6558,7 @@ enum {
 	ALC662_FIXUP_ASUS_MODE8,
 	ALC662_FIXUP_NO_JACK_DETECT,
 	ALC662_FIXUP_ZOTAC_Z68,
+	ALC662_FIXUP_INV_DMIC,
 };
 
 static const struct alc_fixup alc662_fixups[] = {
@@ -6597,12 +6715,17 @@ static const struct alc_fixup alc662_fixups[] = {
 			{ }
 		}
 	},
+	[ALC662_FIXUP_INV_DMIC] = {
+		.type = ALC_FIXUP_FUNC,
+		.v.func = alc662_fixup_inv_dmic,
+	},
 };
 
 static const struct snd_pci_quirk alc662_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
 	SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
 	SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
+	SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x1025, 0x038b, "Acer Aspire 8943G", ALC662_FIXUP_ASPIRE),
 	SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
 	SND_PCI_QUIRK(0x1043, 0x8469, "ASUS mobo", ALC662_FIXUP_NO_JACK_DETECT),
-- 
1.7.10.4

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/22/2012 02:46 PM, Takashi Iwai wrote:
>   /*
> + * Inverted digital-mic handling
> + *
> + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
> + * gives the additional mute only to the right channel of the digital mic
> + * capture stream.  This is a workaround for avoiding the almost silence
> + * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

> + * digital mic unit.
> + *
> + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
> + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
> + * without caching so that the cache can still keep the original value.
> + * The cached value is then restored when the flag is set off or any other
> + * than d-mic is used as the current input source.

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that 
is that you can get a short signal spike on the right channel when you 
turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it 
is not a practical problem.

Thanks for looking at this long-standing problem :-)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Fri, 22 Jun 2012 17:27:51 +0200,
David Henningsson wrote:
> 
> On 06/22/2012 02:46 PM, Takashi Iwai wrote:
> >   /*
> > + * Inverted digital-mic handling
> > + *
> > + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
> > + * gives the additional mute only to the right channel of the digital mic
> > + * capture stream.  This is a workaround for avoiding the almost silence
> > + * by summing the stereo stereo stream from some (known to be ForteMedia)
> 
> Stereo stereo? It's "stereo" in stereo! :-)

Yeah, quad channels.  Fixed now.

> > + * digital mic unit.
> > + *
> > + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
> > + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
> > + * without caching so that the cache can still keep the original value.
> > + * The cached value is then restored when the flag is set off or any other
> > + * than d-mic is used as the current input source.
> 
> Ok, I get it now.
> 
> There is a slight drawback with this (IMO a bit hacky) patch, and that 
> is that you can get a short signal spike on the right channel when you 
> turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it 
> is not a practical problem.

Right, I fully admit it's hacky :)

A good thing by this is, however, that it doesn't touch other parts
too intrusively but just wraps over it.

> Thanks for looking at this long-standing problem :-)

I'm going to commit it once after hearing the test with a real machine
from Eliot.

Thanks for your review!


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

On 06/22/2012 05:37 PM, Takashi Iwai wrote:
> At Fri, 22 Jun 2012 17:27:51 +0200,
> David Henningsson wrote:
>>
>> On 06/22/2012 02:46 PM, Takashi Iwai wrote:
>>>    /*
>>> + * Inverted digital-mic handling
>>> + *
>>> + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
>>> + * gives the additional mute only to the right channel of the digital mic
>>> + * capture stream.  This is a workaround for avoiding the almost silence
>>> + * by summing the stereo stereo stream from some (known to be ForteMedia)
>>
>> Stereo stereo? It's "stereo" in stereo! :-)
>
> Yeah, quad channels.  Fixed now.
>
>>> + * digital mic unit.
>>> + *
>>> + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
>>> + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
>>> + * without caching so that the cache can still keep the original value.
>>> + * The cached value is then restored when the flag is set off or any other
>>> + * than d-mic is used as the current input source.
>>
>> Ok, I get it now.
>>
>> There is a slight drawback with this (IMO a bit hacky) patch, and that
>> is that you can get a short signal spike on the right channel when you
>> turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it
>> is not a practical problem.
>
> Right, I fully admit it's hacky :)
>
> A good thing by this is, however, that it doesn't touch other parts
> too intrusively but just wraps over it.
>
>> Thanks for looking at this long-standing problem :-)
>
> I'm going to commit it once after hearing the test with a real machine
> from Eliot.

Hi,

I'm adding the machines I know of in the patch attached (please commit 
together with your patch).

For users running Ubuntu 12.04 (I think Eliot does), I have also made a 
dkms package for easy testing of these two patches, and I also asked 
existing bug reporters to test it.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Happy weekend!

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[-- Attachment #2: 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch --]
[-- Type: text/x-patch, Size: 2775 bytes --]

>From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Fri, 22 Jun 2012 19:12:10 +0200
Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
 1810TZ and AOD260

These machines have inverted phase on right channel for their
internal mics.

BugLink: https://bugs.launchpad.net/bugs/997227
BugLink: https://bugs.launchpad.net/bugs/996611
BugLink: https://bugs.launchpad.net/bugs/1006089
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 sound/pci/hda/patch_realtek.c |   23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 53cd730..9be7da1 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5918,6 +5918,14 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec,
 	}
 }
 
+static void alc269_fixup_inv_dmic(struct hda_codec *codec,
+				  const struct alc_fixup *fix, int action)
+{
+	if (action == ALC_FIXUP_ACT_PROBE)
+		alc_add_inv_dmic_mixer(codec, 0x12);
+}
+
+
 enum {
 	ALC269_FIXUP_SONY_VAIO,
 	ALC275_FIXUP_SONY_VAIO_GPIO2,
@@ -5936,6 +5944,7 @@ enum {
 	ALC269VB_FIXUP_AMIC,
 	ALC269VB_FIXUP_DMIC,
 	ALC269_FIXUP_MIC2_MUTE_LED,
+	ALC269_FIXUP_INV_DMIC,
 };
 
 static const struct alc_fixup alc269_fixups[] = {
@@ -6060,12 +6069,19 @@ static const struct alc_fixup alc269_fixups[] = {
 		.type = ALC_FIXUP_FUNC,
 		.v.func = alc269_fixup_mic2_mute,
 	},
+	[ALC269_FIXUP_INV_DMIC] = {
+		.type = ALC_FIXUP_FUNC,
+		.v.func = alc269_fixup_inv_dmic,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+	SND_PCI_QUIRK(0x1025, 0x029b, "Acer 1810TZ", ALC269_FIXUP_INV_DMIC),
+	SND_PCI_QUIRK(0x1025, 0x0349, "Acer AOD260", ALC269_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_MIC2_MUTE_LED),
 	SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
+	SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x834a, "ASUS S101", ALC269_FIXUP_STEREO_DMIC),
@@ -6534,12 +6550,7 @@ static void alc272_fixup_mario(struct hda_codec *codec,
 		       "hda_codec: failed to override amp caps for NID 0x2\n");
 }
 
-static void alc662_fixup_inv_dmic(struct hda_codec *codec,
-				  const struct alc_fixup *fix, int action)
-{
-	if (action == ALC_FIXUP_ACT_PROBE)
-		alc_add_inv_dmic_mixer(codec, 0x12);
-}
+#define alc662_fixup_inv_dmic alc269_fixup_inv_dmic
 
 enum {
 	ALC662_FIXUP_ASPIRE,
-- 
1.7.9.5


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [RFC PATCH] Inverted internal mic

[Eliot Blennerhassett]

On 23/06/12 05:33, David Henningsson wrote:
> For users running Ubuntu 12.04 (I think Eliot does), I have also made a
> dkms package for easy testing of these two patches, and I also asked
> existing bug reporters to test it.
> 
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Thanks David,

I can confirm that the right channel is muted when "Inverted Internal
Mic" is "off".  and e.g. skype test call works well.

BTW I initially assumed that "on" == "fix inverted internal mic"  rather
than "on" == "Enable Internal Mic Right Channel"

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Fri, 22 Jun 2012 19:33:06 +0200,
David Henningsson wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> On 06/22/2012 05:37 PM, Takashi Iwai wrote:
> > At Fri, 22 Jun 2012 17:27:51 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/22/2012 02:46 PM, Takashi Iwai wrote:
> >>>    /*
> >>> + * Inverted digital-mic handling
> >>> + *
> >>> + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
> >>> + * gives the additional mute only to the right channel of the digital mic
> >>> + * capture stream.  This is a workaround for avoiding the almost silence
> >>> + * by summing the stereo stereo stream from some (known to be ForteMedia)
> >>
> >> Stereo stereo? It's "stereo" in stereo! :-)
> >
> > Yeah, quad channels.  Fixed now.
> >
> >>> + * digital mic unit.
> >>> + *
> >>> + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
> >>> + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
> >>> + * without caching so that the cache can still keep the original value.
> >>> + * The cached value is then restored when the flag is set off or any other
> >>> + * than d-mic is used as the current input source.
> >>
> >> Ok, I get it now.
> >>
> >> There is a slight drawback with this (IMO a bit hacky) patch, and that
> >> is that you can get a short signal spike on the right channel when you
> >> turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it
> >> is not a practical problem.
> >
> > Right, I fully admit it's hacky :)
> >
> > A good thing by this is, however, that it doesn't touch other parts
> > too intrusively but just wraps over it.
> >
> >> Thanks for looking at this long-standing problem :-)
> >
> > I'm going to commit it once after hearing the test with a real machine
> > from Eliot.
> 
> Hi,
> 
> I'm adding the machines I know of in the patch attached (please commit 
> together with your patch).
> 
> For users running Ubuntu 12.04 (I think Eliot does), I have also made a 
> dkms package for easy testing of these two patches, and I also asked 
> existing bug reporters to test it.
> 
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb
> 
> Happy weekend!
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> [2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]
> >From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
> From: David Henningsson <david.henningsson@canonical.com>
> Date: Fri, 22 Jun 2012 19:12:10 +0200
> Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
>  1810TZ and AOD260
> 
> These machines have inverted phase on right channel for their
> internal mics.

These are all ALC269, and we have already a workaround using the
hardware COEF verb.  Could you check whether it works or not?
There are variants for alc269, alc269vb and alc271.  One of them
might match.

The patch below adds model strings for these fixups for convenience.


Takashi

---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 41475ae..ed40c91 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6031,6 +6031,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 static const struct alc_model_fixup alc269_fixup_models[] = {
 	{.id = ALC269_FIXUP_AMIC, .name = "laptop-amic"},
 	{.id = ALC269_FIXUP_DMIC, .name = "laptop-dmic"},
+	{.id = ALC269_FIXUP_STEREO_DMIC, .name = "alc269-dmic"},
+	{.id = ALC269VB_FIXUP_DMIC, .name = "alc269vb-dmic"},
+	{.id = ALC271_FIXUP_DMIC, .name = "alc271-dmic"},
 	{}
 };
 

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Sat, 23 Jun 2012 14:58:31 +1200,
Eliot Blennerhassett wrote:
> 
> On 23/06/12 05:33, David Henningsson wrote:
> > For users running Ubuntu 12.04 (I think Eliot does), I have also made a
> > dkms package for easy testing of these two patches, and I also asked
> > existing bug reporters to test it.
> > 
> > https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb
> 
> Thanks David,
> 
> I can confirm that the right channel is muted when "Inverted Internal
> Mic" is "off".  and e.g. skype test call works well.

Thanks, I'll apply the patch later then.

> BTW I initially assumed that "on" == "fix inverted internal mic"  rather
> than "on" == "Enable Internal Mic Right Channel"

It's no "mute" switch but "enable" switch.  I follow the logic in
conexant codec driver.
(But yes, it's a bit confusing.)


Takashi

Re: [RFC PATCH] Inverted internal mic

[David Henningsson]

On 06/23/2012 10:39 AM, Takashi Iwai wrote:
> At Fri, 22 Jun 2012 19:33:06 +0200,
> David Henningsson wrote:
>>
>> [1  <text/plain; ISO-8859-1 (7bit)>]
>> On 06/22/2012 05:37 PM, Takashi Iwai wrote:
>>> At Fri, 22 Jun 2012 17:27:51 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 06/22/2012 02:46 PM, Takashi Iwai wrote:
>>>>>     /*
>>>>> + * Inverted digital-mic handling
>>>>> + *
>>>>> + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
>>>>> + * gives the additional mute only to the right channel of the digital mic
>>>>> + * capture stream.  This is a workaround for avoiding the almost silence
>>>>> + * by summing the stereo stereo stream from some (known to be ForteMedia)
>>>>
>>>> Stereo stereo? It's "stereo" in stereo! :-)
>>>
>>> Yeah, quad channels.  Fixed now.
>>>
>>>>> + * digital mic unit.
>>>>> + *
>>>>> + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
>>>>> + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
>>>>> + * without caching so that the cache can still keep the original value.
>>>>> + * The cached value is then restored when the flag is set off or any other
>>>>> + * than d-mic is used as the current input source.
>>>>
>>>> Ok, I get it now.
>>>>
>>>> There is a slight drawback with this (IMO a bit hacky) patch, and that
>>>> is that you can get a short signal spike on the right channel when you
>>>> turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it
>>>> is not a practical problem.
>>>
>>> Right, I fully admit it's hacky :)
>>>
>>> A good thing by this is, however, that it doesn't touch other parts
>>> too intrusively but just wraps over it.
>>>
>>>> Thanks for looking at this long-standing problem :-)
>>>
>>> I'm going to commit it once after hearing the test with a real machine
>>> from Eliot.
>>
>> Hi,
>>
>> I'm adding the machines I know of in the patch attached (please commit
>> together with your patch).
>>
>> For users running Ubuntu 12.04 (I think Eliot does), I have also made a
>> dkms package for easy testing of these two patches, and I also asked
>> existing bug reporters to test it.
>>
>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb
>>
>> Happy weekend!
>>
>> --
>> David Henningsson, Canonical Ltd.
>> https://launchpad.net/~diwic
>> [2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]
>> >From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
>> From: David Henningsson <david.henningsson@canonical.com>
>> Date: Fri, 22 Jun 2012 19:12:10 +0200
>> Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
>>   1810TZ and AOD260
>>
>> These machines have inverted phase on right channel for their
>> internal mics.
>
> These are all ALC269, and we have already a workaround using the
> hardware COEF verb.  Could you check whether it works or not?
> There are variants for alc269, alc269vb and alc271.  One of them
> might match.

Do we really have coefs for alc269vb?
The ALC269VB_FIXUP_DMIC fixup looks like it's pins only, and I've 
confirmed that the alc269 verb does not work for alc269vb, so I assume 
that verb is alc269va only.

Am I missing something?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [RFC PATCH] Inverted internal mic

[Takashi Iwai]

At Mon, 25 Jun 2012 10:04:26 +0200,
David Henningsson wrote:
> 
> On 06/23/2012 10:39 AM, Takashi Iwai wrote:
> > At Fri, 22 Jun 2012 19:33:06 +0200,
> > David Henningsson wrote:
> >>
> >> [1  <text/plain; ISO-8859-1 (7bit)>]
> >> On 06/22/2012 05:37 PM, Takashi Iwai wrote:
> >>> At Fri, 22 Jun 2012 17:27:51 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 06/22/2012 02:46 PM, Takashi Iwai wrote:
> >>>>>     /*
> >>>>> + * Inverted digital-mic handling
> >>>>> + *
> >>>>> + * First off, it's a bit tricky.  The "Inverted Internal Mic Capture Switch"
> >>>>> + * gives the additional mute only to the right channel of the digital mic
> >>>>> + * capture stream.  This is a workaround for avoiding the almost silence
> >>>>> + * by summing the stereo stereo stream from some (known to be ForteMedia)
> >>>>
> >>>> Stereo stereo? It's "stereo" in stereo! :-)
> >>>
> >>> Yeah, quad channels.  Fixed now.
> >>>
> >>>>> + * digital mic unit.
> >>>>> + *
> >>>>> + * The logic is to call alc_inv_dmic_sync() after each action (possibly)
> >>>>> + * modifying ADC amp.  When the mute flag is set, it mutes the R-channel
> >>>>> + * without caching so that the cache can still keep the original value.
> >>>>> + * The cached value is then restored when the flag is set off or any other
> >>>>> + * than d-mic is used as the current input source.
> >>>>
> >>>> Ok, I get it now.
> >>>>
> >>>> There is a slight drawback with this (IMO a bit hacky) patch, and that
> >>>> is that you can get a short signal spike on the right channel when you
> >>>> turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it
> >>>> is not a practical problem.
> >>>
> >>> Right, I fully admit it's hacky :)
> >>>
> >>> A good thing by this is, however, that it doesn't touch other parts
> >>> too intrusively but just wraps over it.
> >>>
> >>>> Thanks for looking at this long-standing problem :-)
> >>>
> >>> I'm going to commit it once after hearing the test with a real machine
> >>> from Eliot.
> >>
> >> Hi,
> >>
> >> I'm adding the machines I know of in the patch attached (please commit
> >> together with your patch).
> >>
> >> For users running Ubuntu 12.04 (I think Eliot does), I have also made a
> >> dkms package for easy testing of these two patches, and I also asked
> >> existing bug reporters to test it.
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb
> >>
> >> Happy weekend!
> >>
> >> --
> >> David Henningsson, Canonical Ltd.
> >> https://launchpad.net/~diwic
> >> [2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]
> >> >From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
> >> From: David Henningsson <david.henningsson@canonical.com>
> >> Date: Fri, 22 Jun 2012 19:12:10 +0200
> >> Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
> >>   1810TZ and AOD260
> >>
> >> These machines have inverted phase on right channel for their
> >> internal mics.
> >
> > These are all ALC269, and we have already a workaround using the
> > hardware COEF verb.  Could you check whether it works or not?
> > There are variants for alc269, alc269vb and alc271.  One of them
> > might match.
> 
> Do we really have coefs for alc269vb?
> The ALC269VB_FIXUP_DMIC fixup looks like it's pins only, and I've 
> confirmed that the alc269 verb does not work for alc269vb, so I assume 
> that verb is alc269va only.

Ah, right.  I forgot that it's specific to ALC269, not VB variant.
I'll apply your patch, then.


thanks,

Takashi

[RFC PATCH] Inverted internal mic

[rodney byne]

Hello to David Henningsson and associates,

I have been trawling the internet to find out
why the internal mic on my Acer Aspire One AOA-110
netbook is permanently inhibited by Alsa.
This little pc runs Linux Peppermint 5 OS, which contains
PulseAudio ESD over-riding the Alsa sound architecture.

Thinking initially this was a "programming" fault, I
have read as much of the history up to the patch need as
I can understand and so appreciate this action on your
part was deliberate - but must comment nonetheless that
this matter is disconcerting from a casual user perspective.

In short, the owner just wants everything on his
machine to work normally and so I would really like to
use the internal mic function for what it was intended.

Personally I have often wondered why PA was ever introduced,
as Alsa & AlsaMixer are perfectly capable of working on
their own, as testament to early releases of Linux Mint.
My opinion is PA just makes the sound system too complicated.
I call it guilding the lilly - so use the principle K.I.S.S

My question therefore is, can the patch be easily lifted
at will to re-enable the internal microphone?

Thanks and best regards,
from Rodney.