[Lenovo IdeaPad U300s, Conexant CX20590, Mic, Internal] Background noise or low volume (phase inversion)

Output from alsa-info script attached.

Hi Stuart,
I know Skype likes to tweak input level controls for some weird reason, but I think it has an option to disable the controlling of input levels in the audio settings somewhere. Have you found this and tried to disable it? I am not sure if mumble as the same option, but its worth checking for.

Luke,

The problem also occurs with empathy using google talk, *and* it occurs with a separate USB mic (that is: the separate USB mic works fine in Sound Recorder but is unhearably quiet when using skype, mumble, and empathy); I suppose it's possible that skype, mumble, and empathy all do the same input-level tweaking, but I can't find anything obvious in all three apps which suggests that they're doing so? I am most baffled.

Attached pacmd ls output while making a broken recording (specifically, going through the mumble audio wizard, which shows me speaking very quietly indeed).

Updated information:

if I start twinkle (voip app) and gnome-sound-recorder at the same time, and set both to record (that is: call an echo test SIP number from twinkle, and hit record in g-s-r) then g-s-r records my voice at normal volume perfectly, and twinkle doesn't hear any sound from me unless I shout. This is using the internal mic: no external mics are plugged in.

Status changed to 'Confirmed' because the bug affects multiple users.

OK, thanks to diwic, there is a known workaround.

1. Install the "Pulseaudio Volume Control" application from Software Center
2. Open "Pulseaudio Volume Control" from the Dash
3. In the Input Devices tab, select "Analogue Input" in "Port:"
4. Deselect the padlock so that the channels are not linked together
5. Drag the Front Right channel all the way to the left: 0% (-∞dB)
6. Set Front Left to whatever mic volume you choose (e.g., 100%)

Skype and Mumble should now work fine. The microphone volume control which appears in the Sound Menu will also now work to control your mic volume in Skype/Mumble (it controls only the Front Left volume when Front Right is 0%).

This doesn't fix the bug, per se, but it does let affected technical people fix it for themselves.

Hey!

I finally had some time to sketch on a patch to resolve this problem. Could you please installed the attached dkms package, reboot, and see if it resolves your problem?

For reference, here's the patch applied - it's probably not really as elegant as I want it yet, and I'll ask upstream for comments as well, but I want to know that it works before continuing.

Thanks!

This patch seems to have fixed the problem! I installed the provided deb (and had to install dkms too), and now the mic works. Excellent!

The attachment "0001-Fix-internal-mic-for-Lenovo-Ideapad-U300s.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

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

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

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

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

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.

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

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://laun...

Judging from the lack of responses to the email below, seems like we'll have to live with this bug in 12.04 :-/

https://lists.ubuntu.com/archives/kernel-team/2012-March/019393.html

The internal mic input is phase inverted on one channel.
To avoid people in userspace summing the channels together
and get zero result, use a separate mixer control for the
inverted channel.

BugLink: https://bugs.launchpad.net/bugs/903853
Signed-off-by: David Henningsson <email address hidden>
---
 sound/pci/hda/patch_conexant.c | 88 ++++++++++++++++++++++++++++++++++------
 1 files changed, 75 insertions(+), 13 deletions(-)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index e6eafb1..c18e3b1 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -142,6 +142,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;

@@ -4107,9 +4108,9 @@ 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 char name[44];
  static struct snd_kcontrol_new knew[] = {
   HDA_CODEC_VOLUME(name, 0, 0, 0),
   HDA_CODEC_MUTE(name, 0, 0, 0),
@@ -4119,7 +4120,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;
@@ -4138,7 +4139,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)
@@ -4208,6 +4209,36 @@ static int cx_auto_build_output_controls(struct hda_codec *codec)
  return 0;
 }

+/* Returns zero if this is a normal stereo channel, and non-zero if it should
+ be split in two independent channels.
+ dest_label must be at least 44 characters. */
+static int cx_auto_get_rightch_label(struct hda_codec *codec, const char *label,
+ char *dest_label, int nid)
+{
+ struct conexant_spec *spec = codec->spec;
+ int i;
+
+ if (!spec->fixup_stereo_dmic)
+ return 0;
+
+ for (i = 0; i < AUTO_CFG_MAX_INS; i++) {
+ int def_conf;
+ if (spec->autocfg.inputs[i].pin != nid)
+ continue;
+
+ if (spec->autocfg.inputs[i].type != AUTO_PIN_MIC)
+ return 0;
+ def_conf = snd_hda_codec_get_pincfg(codec, nid);
+ if (snd_hda_get_input_pin_attr(def_conf) != INPUT_PIN_ATTR_INT)
+ return 0;
+
+ /* Finally found the inverted internal mic! */
+ snprintf(dest_label, 44, "Inverted %s", label);
+ return 1;
+ }
+ return 0;
+}
+
 static int cx_auto_add_capture_volume(struct hda_codec *codec, hda_nid_t nid,
           const char *label, const char *pfx,...

I have now got a patch committed into upstream ALSA, but not the 12.04 kernel. That means the following:
1) You can use the https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS way to upgrade your sound drivers. (They are currently building, but should have finished building by the time you read this hopefully)
2) After a reboot, go into alsamixer and make sure the new "Inverted Internal Mic" control is muted.

References:

You need these two patches to make it work:
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=18dcd3044e4c4b3ab6341c98e8d0e81e0d58d5e3
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=83b0c6ba999643ee8ad6329f26e1cdc870e1a920

They are scheduled for Linux 3.5. I don't think they made it into Linux 3.4.

This bug was fixed in the package linux - 3.5.0-1.1

---------------
linux (3.5.0-1.1) quantal-proposed; urgency=low

  [ Andy Whitcroft ]

  * [Config] highbank -- enable CONFIG_RFKILL=y and CONFIG_CAN=m

  [ Leann Ogasawara ]

  * Rebase to v3.5-rc1
  * [Config] Remove USB_DEVICEFS from the config enforcer
  * [Config] Updateconfigs after rebase to v3.5-rc1
  * [Config] Temporarily disable CONFIG_MACH_NOKIA_RX51 on arm
  * [Config] Temporarily disable CONFIG_TOUCHSCREEN_EETI on arm
  * [Config] Temporarily disable CONFIG_TOUCHSCREEN_EGALAX on arm
  * [Config] Temporarily disable CONFIG_EZX_PCAP on arm
  * [Config] Temporarily disable CONFIG_LIS3L02DQ on arm
  * [Config] Temporarily disable CONFIG_TI_CPSW on arm
  * [Config] Temporarily disable CONFIG_GPIO_EM on arm
  * [Config] Temporarily disable CONFIG_SERIAL_8250_EM on armhf
  * [Config] Temporarily disable CONFIG_STMMAC_ETH on armhf
  * [Config] Temporarily disable CONFIG_HW_RANDOM_ATMEL on armhf
  * Rebase to v3.5-rc2
  * [Config] Updateconfigs after rebase to v3.5-rc2
  * [Config] Temporarily disable CONFIG_MV643XX_ETH on powerpc
  * Rebase to v3.5-rc3
  * [Config] Updateconfigs after rebase to v3.5-rc3

  [ Paul Mundt ]

  * SAUCE: fix bug.h's inclusion of kernel.h

  [ Stefan Bader ]

  * SAUCE: Fix compile failures of dm-raid45
  * [Config] Enable dm-raid45
  * Move dependency on crda to extra package
    - LP: #657901
  * SAUCE: Mask CR4 writes on older Xen hypervisors

  [ Upstream Kernel Changes ]

  * rebase to v3.5-rc3
    - LP: #993162
    - LP: #925577
  * rebase to v3.5-rc2
  * rebase to v3.5-rc1
    - LP: #955892
    - LP: #978038
    - LP: #987371
    - LP: #929545
    - LP: #942316
    - LP: #903853
 -- Leann Ogasawara <email address hidden> Fri, 08 Jun 2012 14:28:46 -0700

If you backport this to 12.04, make sure you also catch

commit 83b0c6ba999643ee8ad6329f26e1cdc870e1a920
Author: David Henningsson <email address hidden>
Date: Tue Apr 10 13:05:29 2012 +0200

    ALSA: hda - Fix oops caused by recent commit "Fix internal mic for Lenovo Ideapad U300s"

and not only this one:

commit 18dcd3044e4c4b3ab6341c98e8d0e81e0d58d5e3
Author: David Henningsson <email address hidden>
Date: Mon Apr 2 15:40:27 2012 +0200

    ALSA: hda - Fix internal mic for Lenovo Ideapad U300s

Hi I've cherry-picked the two commits that diwic recommended, built them and uploaded them here:

http://people.canonical.com/~arges/lp903853/

Please test with this package to see if it works.

SRU for precise sent to ubuntu kernel ML.
--chris

This bug is awaiting verification that the kernel for Precise in -proposed solves the problem (3.2.0-29.46). Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-precise' to 'verification-done-precise'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Verified new kernel as working.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package linux - 3.2.0-29.46

---------------
linux (3.2.0-29.46) precise-proposed; urgency=low

  [ Tim Gardner ]

  * No change upload to fix armel/armhf FTBS caused by
    'UBUNTU: [Config] SND_OMAP_SOC, SND_OMAP_SOC_MCBSP and SND_OMAP_SOC_OMAP3_BEAGLE =y'
    Added ignore and ignore.module files to ABI directories.

  [Luis Henriques]

  * Release Tracking Bug
    - LP: #1029507

linux (3.2.0-29.45) precise-proposed; urgency=low

  [Luis Henriques]

  * Release Tracking Bug
    - LP: #1029507

  [ Andy Whitcroft ]

  * SAUCE: rds_ib_send() -- prevent local pings triggering BUG_ON()
    - LP: #1016299
    - CVE-2012-2372

  [ Upstream Kernel Changes ]

  * Revert "samsung-laptop: make the dmi check less strict"
    - LP: #1029431
  * samsung-laptop: make the dmi check less strict
    - LP: #1029431
  * raid5: delayed stripe fix
    - LP: #1029431
  * tcp: drop SYN+FIN messages
    - LP: #1029431
  * tg3: Apply short DMA frag workaround to 5906
    - LP: #1029431
  * rtl8187: ->brightness_set can not sleep
    - LP: #1029431
  * net/wireless: ipw2x00: add supported cipher suites to wiphy
    initialization
    - LP: #1029431
  * kbuild: do not check for ancient modutils tools
    - LP: #1029431
  * brcmsmac: "INTERMEDIATE but not AMPDU" only when tracing
    - LP: #1029431
  * ext4: Report max_batch_time option correctly
    - LP: #1029431
  * NFSv4: Reduce the footprint of the idmapper
    - LP: #1029431
  * NFSv4: Further reduce the footprint of the idmapper
    - LP: #1029431
  * macvtap: zerocopy: fix offset calculation when building skb
    - LP: #1029431
  * macvtap: zerocopy: fix truesize underestimation
    - LP: #1029431
  * macvtap: zerocopy: put page when fail to get all requested user pages
    - LP: #1029431
  * macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built
    successfully
    - LP: #1029431
  * macvtap: zerocopy: validate vectors before building skb
    - LP: #1029431
  * KVM: Fix buffer overflow in kvm_set_irq()
    - LP: #1029431
  * scsi: Silence unnecessary warnings about ioctl to partition
    - LP: #1029431
  * iommu/amd: Fix missing iommu_shutdown initialization in passthrough
    mode
    - LP: #1029431
  * iommu/amd: Initialize dma_ops for hotplug and sriov devices
    - LP: #1029431
  * usb: Add support for root hub port status CAS
    - LP: #1029431
  * gpiolib: wm8994: Pay attention to the value set when enabling as output
    - LP: #1029431
  * sched/nohz: Rewrite and fix load-avg computation -- again
    - LP: #1029431
  * USB: option: add ZTE MF60
    - LP: #1029431
  * USB: option: Add MEDIATEK product ids
    - LP: #1029431
  * USB: cdc-wdm: fix lockup on error in wdm_read
    - LP: #1029431
  * mtd: nandsim: don't open code a do_div helper
    - LP: #1029431
  * dvb-core: Release semaphore on error path dvb_register_device()
    - LP: #1029431
  * hwspinlock/core: use global ID to register hwspinlocks on multiple
    devices
    - LP: #1029431
  * libsas: fix taskfile corruption in sas_ata_qc_fill_rtf
    - LP: #1029431
  * md/raid1: fix use-after-free bug in RAID1 data-check code.
    - LP: #1029431
  * PCI: EHCI: fix crash during suspend on ASUS computers
    - L...

The patch applied to precise had a problem. The quirk for U300 was applied to the wrong list (cxt5051_fixups instead of cxt5066_fixups, looking at original alsa info attached here it will consider cxt5066_fixups). The upstream patch was ok, just the diff applied to precise had this issue. It's now fixed in precise master-next using correct version from 3.2.32 stable update (bug 1068162).