Microphone Not Working after Suspend on Apple MacBookAir5, 2 Cirrus Logic CS4206

Commit Message

Takashi Iwai March 12, 2015, 10:38 a.m. UTC

At Wed, 11 Mar 2015 23:26:00 +0100,
Vasil Zlatanov wrote:
> 
> Issue as seen on reddit thread:
> https://www.reddit.com/r/linux/comments/1kccbk/alsa_bug_driving_me_crazy_please_help/
> 
> A common problem for Apple Macbook Air 5.2 users where microphone does 
> not work after system resume. As users have noted microphone starts 
> working ones again when the volume is changed in alsa-mixer. 
> 
> alsa-info dumps are attached showing before and after being adjusted
> (where before causes microphone not to work while in after it does)
> 
> IRC user 'debianuser' kindly helped out and found that using the two
> following commands fix the issue:
> 
> amixer -cPCH set "Capture" 0% nocap 
> amixer -cPCH set "Capture" 100% cap                                      
> 
> In my experience both are required and they seem to have the same effect
> as manually changing the volume level in alsamixer, and as such resolve
> the issue (until another suspend when they have to be run again).

This might be due to the single ADC amp.  The ADC widgets have
multiple inputs and usually they have individual amp volumes.  But
some codecs give only a single volume for all inputs.

There is a flag in the driver to change the control for that.  The
patch below enables it.


Alternatively, you can pass "single_adc_smp = true" hint in the
firmware patch passed via patch option.  See
Documentation/sound/alsa/HD-Audio.txt for details.


> As of now I'm resolving this issue by creating a service that is to run
> after resume from susspend with the given amixer commands to renable the
> microphone.
> 
> The second issue, which is also in the reddit thread, is that the
> microphine is mono and when recording only right channel audio is seen.
> For me this broke programs such as mumble and skype.
> 
> A alsa-info output with coefficients is attached.
> 
> 'debianuser' managed to find a solution to this issue well, resolving it
> by running the following two commands:
> 
> hda-verb /dev/snd/hwC0D0 0x11 SET_COEF_INDEX 2
> hda-verb /dev/snd/hwC0D0 0x11 SET_PROC_COEF 0x102a
> 
> After one runs them a single time after boot, the channels collectly
> show and programs issues are resolved. 'debianuser' mentions that the
> sources for the commands are available in the kernel and applied to the
> macbook 8.1 model, but not to mine.

Yes, it's the very same workaround for MBP8,1.  You can pass
model=mbp81 option.  If it works, you can just add a sline to
cs420x_fixup_tbl[] something like

@@ -393,6 +393,7 @@ static const struct snd_pci_quirk cs420x_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81),
 	SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122),
 	SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),
+	SND_PCI_QUIRK(0x106b, 0x5600, "MacBookAir 5,2", CS420X_MBP81),
 	SND_PCI_QUIRK(0x106b, 0x5b00, "MacBookAir 4,2", CS420X_MBA42),
 	SND_PCI_QUIRK_VENDOR(0x106b, "Apple", CS420X_APPLE),
 	{} /* terminator */



Takashi

Comments

Takashi Iwai March 12, 2015, 7:52 p.m. UTC | #1

At Thu, 12 Mar 2015 20:13:05 +0100,
Vasil Zlatanov wrote:
> 
> Applied both patches against 3.18.6-1 and correctly resolved all
> issues.

Good to hear, I queued both patches now.  They'll be backported to
stable kernels once when merged to upstream.


thanks,

Takashi

> 
> On Thu, Mar 12, 2015 at 11:38:39AM +0100, Takashi Iwai wrote:
> > At Wed, 11 Mar 2015 23:26:00 +0100,
> > Vasil Zlatanov wrote:
> > > 
> > > Issue as seen on reddit thread:
> > > https://www.reddit.com/r/linux/comments/1kccbk/alsa_bug_driving_me_crazy_please_help/
> > > 
> > > A common problem for Apple Macbook Air 5.2 users where microphone does 
> > > not work after system resume. As users have noted microphone starts 
> > > working ones again when the volume is changed in alsa-mixer. 
> > > 
> > > alsa-info dumps are attached showing before and after being adjusted
> > > (where before causes microphone not to work while in after it does)
> > > 
> > > IRC user 'debianuser' kindly helped out and found that using the two
> > > following commands fix the issue:
> > > 
> > > amixer -cPCH set "Capture" 0% nocap 
> > > amixer -cPCH set "Capture" 100% cap                                      
> > > 
> > > In my experience both are required and they seem to have the same effect
> > > as manually changing the volume level in alsamixer, and as such resolve
> > > the issue (until another suspend when they have to be run again).
> > 
> > This might be due to the single ADC amp.  The ADC widgets have
> > multiple inputs and usually they have individual amp volumes.  But
> > some codecs give only a single volume for all inputs.
> > 
> > There is a flag in the driver to change the control for that.  The
> > patch below enables it.
> > 
> > diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
> > index 1589c9bcce3e..dd2b3d92071f 100644
> > --- a/sound/pci/hda/patch_cirrus.c
> > +++ b/sound/pci/hda/patch_cirrus.c
> > @@ -584,6 +584,7 @@ static int patch_cs420x(struct hda_codec *codec)
> >  		return -ENOMEM;
> >  
> >  	spec->gen.automute_hook = cs_automute;
> > +	codec->single_adc_amp = 1;
> >  
> >  	snd_hda_pick_fixup(codec, cs420x_models, cs420x_fixup_tbl,
> >  			   cs420x_fixups);
> > 
> > Alternatively, you can pass "single_adc_smp = true" hint in the
> > firmware patch passed via patch option.  See
> > Documentation/sound/alsa/HD-Audio.txt for details.
> > 
> > 
> > > As of now I'm resolving this issue by creating a service that is to run
> > > after resume from susspend with the given amixer commands to renable the
> > > microphone.
> > > 
> > > The second issue, which is also in the reddit thread, is that the
> > > microphine is mono and when recording only right channel audio is seen.
> > > For me this broke programs such as mumble and skype.
> > > 
> > > A alsa-info output with coefficients is attached.
> > > 
> > > 'debianuser' managed to find a solution to this issue well, resolving it
> > > by running the following two commands:
> > > 
> > > hda-verb /dev/snd/hwC0D0 0x11 SET_COEF_INDEX 2
> > > hda-verb /dev/snd/hwC0D0 0x11 SET_PROC_COEF 0x102a
> > > 
> > > After one runs them a single time after boot, the channels collectly
> > > show and programs issues are resolved. 'debianuser' mentions that the
> > > sources for the commands are available in the kernel and applied to the
> > > macbook 8.1 model, but not to mine.
> > 
> > Yes, it's the very same workaround for MBP8,1.  You can pass
> > model=mbp81 option.  If it works, you can just add a sline to
> > cs420x_fixup_tbl[] something like
> > 
> > @@ -393,6 +393,7 @@ static const struct snd_pci_quirk cs420x_fixup_tbl[] = {
> >  	SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81),
> >  	SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122),
> >  	SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),
> > +	SND_PCI_QUIRK(0x106b, 0x5600, "MacBookAir 5,2", CS420X_MBP81),
> >  	SND_PCI_QUIRK(0x106b, 0x5b00, "MacBookAir 4,2", CS420X_MBA42),
> >  	SND_PCI_QUIRK_VENDOR(0x106b, "Apple", CS420X_APPLE),
> >  	{} /* terminator */
> > 
> > 
> > 
> > Takashi
> [2  <application/pgp-signature (7bit)>]
>

Vasil Zlatanov March 12, 2015, 7:53 p.m. UTC | #2

(Reply to all) Applied patches against 3.18.6-1 successfully and both of
the described issues were resolved :). 

* sorry Takashi for double reply

On Thu, Mar 12, 2015 at 11:38:39AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2015 23:26:00 +0100,
> Vasil Zlatanov wrote:
> > 
> > Issue as seen on reddit thread:
> > https://www.reddit.com/r/linux/comments/1kccbk/alsa_bug_driving_me_crazy_please_help/
> > 
> > A common problem for Apple Macbook Air 5.2 users where microphone does 
> > not work after system resume. As users have noted microphone starts 
> > working ones again when the volume is changed in alsa-mixer. 
> > 
> > alsa-info dumps are attached showing before and after being adjusted
> > (where before causes microphone not to work while in after it does)
> > 
> > IRC user 'debianuser' kindly helped out and found that using the two
> > following commands fix the issue:
> > 
> > amixer -cPCH set "Capture" 0% nocap 
> > amixer -cPCH set "Capture" 100% cap                                      
> > 
> > In my experience both are required and they seem to have the same effect
> > as manually changing the volume level in alsamixer, and as such resolve
> > the issue (until another suspend when they have to be run again).
> 
> This might be due to the single ADC amp.  The ADC widgets have
> multiple inputs and usually they have individual amp volumes.  But
> some codecs give only a single volume for all inputs.
> 
> There is a flag in the driver to change the control for that.  The
> patch below enables it.
> 
> diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
> index 1589c9bcce3e..dd2b3d92071f 100644
> --- a/sound/pci/hda/patch_cirrus.c
> +++ b/sound/pci/hda/patch_cirrus.c
> @@ -584,6 +584,7 @@ static int patch_cs420x(struct hda_codec *codec)
>  		return -ENOMEM;
>  
>  	spec->gen.automute_hook = cs_automute;
> +	codec->single_adc_amp = 1;
>  
>  	snd_hda_pick_fixup(codec, cs420x_models, cs420x_fixup_tbl,
>  			   cs420x_fixups);
> 
> Alternatively, you can pass "single_adc_smp = true" hint in the
> firmware patch passed via patch option.  See
> Documentation/sound/alsa/HD-Audio.txt for details.
> 
> 
> > As of now I'm resolving this issue by creating a service that is to run
> > after resume from susspend with the given amixer commands to renable the
> > microphone.
> > 
> > The second issue, which is also in the reddit thread, is that the
> > microphine is mono and when recording only right channel audio is seen.
> > For me this broke programs such as mumble and skype.
> > 
> > A alsa-info output with coefficients is attached.
> > 
> > 'debianuser' managed to find a solution to this issue well, resolving it
> > by running the following two commands:
> > 
> > hda-verb /dev/snd/hwC0D0 0x11 SET_COEF_INDEX 2
> > hda-verb /dev/snd/hwC0D0 0x11 SET_PROC_COEF 0x102a
> > 
> > After one runs them a single time after boot, the channels collectly
> > show and programs issues are resolved. 'debianuser' mentions that the
> > sources for the commands are available in the kernel and applied to the
> > macbook 8.1 model, but not to mine.
> 
> Yes, it's the very same workaround for MBP8,1.  You can pass
> model=mbp81 option.  If it works, you can just add a sline to
> cs420x_fixup_tbl[] something like
> 
> @@ -393,6 +393,7 @@ static const struct snd_pci_quirk cs420x_fixup_tbl[] = {
>  	SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81),
>  	SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122),
>  	SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),
> +	SND_PCI_QUIRK(0x106b, 0x5600, "MacBookAir 5,2", CS420X_MBP81),
>  	SND_PCI_QUIRK(0x106b, 0x5b00, "MacBookAir 4,2", CS420X_MBA42),
>  	SND_PCI_QUIRK_VENDOR(0x106b, "Apple", CS420X_APPLE),
>  	{} /* terminator */
> 
> 
> 
> Takashi

Patch

diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index 1589c9bcce3e..dd2b3d92071f 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -584,6 +584,7 @@  static int patch_cs420x(struct hda_codec *codec)
 		return -ENOMEM;
 
 	spec->gen.automute_hook = cs_automute;
+	codec->single_adc_amp = 1;
 
 	snd_hda_pick_fixup(codec, cs420x_models, cs420x_fixup_tbl,
 			   cs420x_fixups);