Bug 60811 - No speaker sound output on MacBook Air 6,2
Summary: No speaker sound output on MacBook Air 6,2
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
: 61741 (view as bug list)
Depends on:
Reported: 2013-08-29 11:13 UTC by Imre Kaloz
Modified: 2013-11-06 07:31 UTC (History)
10 users (show)

See Also:
Kernel Version: 3.11-rc7
Tree: Mainline
Regression: No

alsa-info.sh output (40.11 KB, application/octet-stream)
2013-08-29 11:13 UTC, Imre Kaloz
Test patch (964 bytes, patch)
2013-08-29 11:38 UTC, Takashi Iwai
Details | Diff
alsa-info output with test patch and model=mba42 (71.01 KB, application/octet-stream)
2013-08-29 13:24 UTC, Imre Kaloz
alsa-info output with test patch and no model option (72.17 KB, application/octet-stream)
2013-08-29 13:34 UTC, Imre Kaloz
Test fix patch (3.75 KB, patch)
2013-09-09 09:47 UTC, Takashi Iwai
Details | Diff
Cirrus Logic inf (85.68 KB, application/octet-stream)
2013-09-14 00:00 UTC, sam.attwell
CS4802 config and init patch (4.01 KB, patch)
2013-09-17 10:55 UTC, Ben Whitten
Details | Diff
Formatted patch from Comment #30 (906 bytes, patch)
2013-11-03 22:23 UTC, Alex Markley
Details | Diff
Fix patch for invalid HP amp (2.62 KB, patch)
2013-11-04 16:07 UTC, Takashi Iwai
Details | Diff
alsa-info: sound ok after initial boot (39.23 KB, text/plain)
2013-11-04 16:33 UTC, Christoph
alsa-info: no sound after fourth hibernate (25.87 KB, application/octet-stream)
2013-11-04 16:33 UTC, Christoph

Description Imre Kaloz 2013-08-29 11:13:11 UTC
Created attachment 107352 [details]
alsa-info.sh output

There is no sound output using the internal speakers on the MacBook Air 6,2. Both the internal microphone as well the combined microphone/headphone jack seems to work properly.
Comment 1 Takashi Iwai 2013-08-29 11:38:24 UTC
It seems to have a new unsupported Cirrus codec chip.

Below is a blind shot, with a hope that it's compatible with old CS4206/4207 chips.  Give it a try.

If it still doesn't work, try to pass model=mba42 to snd-hda-intel module.
Other possible values are found in cs402x_models[] in sound/pci/hda/patch_cirrus.c.
Comment 2 Takashi Iwai 2013-08-29 11:38:43 UTC
Created attachment 107353 [details]
Test patch
Comment 3 Imre Kaloz 2013-08-29 13:23:35 UTC
No joy with any of the model options and it seems Cirrus didn't put up any info on this codec, yet.

I'll also attach the output of alsa-info with model=mba42 just in case.
Comment 4 Imre Kaloz 2013-08-29 13:24:39 UTC
Created attachment 107354 [details]
alsa-info output with test patch and model=mba42
Comment 5 Imre Kaloz 2013-08-29 13:34:38 UTC
Created attachment 107356 [details]
alsa-info output with test patch and no model option

Attached one without the model option, too.
Comment 6 Takashi Iwai 2013-08-29 13:35:29 UTC
OK, cs4208 seems utterly incompatible with cs4206 and cs4207.  The pins start from NID 0x10 to 0x22, while NID 0x09-0x15 are pins for CS4206/CS2407, for example.  So disregard the previous patch.  That would just break things.

From now on, only trial-and-error method would work.  First of all, you need to figure out which pin corresponds to which I/O jack.  Usually this can checked by the jack detection of each pin by pluggin/unplugging a jack.  hda-jack-retask or hda-analyzer would be a good help.  See Documentation/sound/alsa/HD-Audio.txt.

After figuring the I/O pins, try to adjust GPIO manually.  Typical Apple machines had GPIO 1 and 3 (2 and 8) for the headphone and the speaker.
But this might be different.
Comment 7 Imre Kaloz 2013-08-29 13:55:52 UTC
Just to confirm, I should check those without the test patch, right?
Comment 8 Takashi Iwai 2013-08-29 15:36:49 UTC
Yes.  The patch is obviously broken.
Comment 9 Miek Gieben 2013-09-01 19:00:26 UTC
I tried hda-jack-retask and set 0x10 up 0x14 (inclusive) to "Internal Speaker" via the override. Each time 'Apply now' and then playing an mp3 with mpg321 -o alsa. However this did not produce any audio
Comment 10 Imre Kaloz 2013-09-01 19:03:02 UTC
hda-analyzer fails to work with the current proc data. Tried hdajackretask, by default it claims the following:

- Green Headphone: pin 0x10
- Internal speaker: pin 0x12
- Pink Mic: pin 0x18
- Internal Mic: pin 0x1c

As I've mentioned above, all these but the internal speaker work.

Possible unconnected pin overrides:

- pin 0x11, 0x13 & 0x14 allows Line out (Front/LFE/BACK/Side) and Internal speaker (plain/LFE/BACK)
- pin 0x15 & pin 0x16 allows Microphone, Line in and Internal mic
- pin 0x17, 0x19, 0x1a &  0x1b only allows Internal mic
- pin 0x1d, 0x1e & 0x21 only allows SPDIF out
- pin 0x1f, 0x20 & 0x22 only allows SPDIF in

Tried overriding the first three to "Internal speaker" and 0x12 to "Not connected", but it didn't make a difference.
Comment 11 Takashi Iwai 2013-09-06 14:10:06 UTC
OK, so the pins seems correctly assigned.  Then the rest is other adjustments like GPIO.  Did you try turn on/off each GPIO pin?
Comment 12 Miek Gieben 2013-09-06 23:01:51 UTC
> Did you try turn on/off each GPIO pin?

I'm sorry, but where can I found documentation on how to do this?
Comment 13 Takashi Iwai 2013-09-09 08:58:32 UTC
For setting GPIO 0,
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x01
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIR 0x01
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x01
for GPIO 1,
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x02
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIR 0x02
   hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x02
For GPIO2, replace 0x02 with 0x04, for GPIO3 with 0x08, and so on.
Comment 14 Imre Kaloz 2013-09-09 09:28:33 UTC
Setting GPIO0 the above way makes the speakers work. If you have a proper patch to test, please let me know.
Comment 15 Takashi Iwai 2013-09-09 09:47:10 UTC
The test fix patch is attached below.  Give it a try.
Comment 16 Takashi Iwai 2013-09-09 09:47:38 UTC
Created attachment 107811 [details]
Test fix patch
Comment 17 Imre Kaloz 2013-09-09 11:30:15 UTC
Works, thank you :) Feel free to add:

Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org>
Comment 18 Miek Gieben 2013-09-09 18:46:11 UTC
Indeed works \o/ However if I now plugin my headset, the speaker's audio isn't muted.
Comment 19 sam.attwell 2013-09-14 00:00:55 UTC
Created attachment 108341 [details]
Cirrus Logic inf


Me and a friend have been working on the jack-sense problem a little and have dug out the Windows (boot camp partition with working speakers and jack) inf for Cirrus Logic chips. I think there may be some init verbs missing and the pin configurations are different.

We think Windows' pin configs are as follows:

0x10 0x032120f0
0x11 0x500000f0
0x12 0x90100010
0x13 0x500000f0
0x14 0x500000f0
0x15 0x770000f0
0x16 0x770000f0
0x17 0x430000f0
0x18 0x43ab9030
0x19 0x770000f0
0x1a 0x770000f0
0x1b 0x770000f0
0x1c 0x90a00090
0x1d 0x500000f0
0x1e 0x500000f0
0x1f 0x500000f0
0x20 0x500000f0
0x21 0x430000f0
0x22 0x430000f0

Perhaps someone knows more than us here.
Comment 20 Ben Whitten 2013-09-17 10:55:11 UTC
Created attachment 108721 [details]
CS4802 config and init patch

I have taken the default settings and setup from the windows environment and tried to apply it to this driver, and the jacksense and automute now work.
Comment 21 Miek Gieben 2013-09-19 13:55:47 UTC
Patch from comment #20 works like a charm (tested on 3.12-rc1)
Comment 22 Miek Gieben 2013-09-19 18:37:56 UTC
Hmmm 3.12-rc: doesn't survive a resume though... :-( No audio at all, neither headphones, nor speakers.
Comment 23 sam.attwell 2013-09-20 15:29:14 UTC
I believe the lack of audio on resume is a separate ACPI issue, neither Cirrus Logic codec or Haswell HDMI get power states after resume.

I have created a separate bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=61741
Comment 24 Miek Gieben 2013-09-21 09:41:30 UTC
Re: 3.12-rc1: I cannot reproduce it anymore. The audio keeps on working after a resume. Strange.
Comment 25 Miek Gieben 2013-09-26 07:29:05 UTC
I think there is a race condition in the $whatever-procedure that happens during resume. As all audio is muted again on my laptop. This is with 3.12-rc2.
Comment 26 Takashi Iwai 2013-09-26 09:02:48 UTC
Great.  Ben, could you give your sign-off for the patch so that I can merge to the upstream?
Comment 27 Ben Whitten 2013-09-26 17:54:10 UTC
Certainly, what I would do is change the hda_nid_t variable name in cs4208_fix_amp_caps to adc not dac, I got that the wrong way around, oops. But if the patch doesn't require any cleanups or better ways to do it feel free to add my;

Signed-off-by: Ben Whitten <benwhitten@gmail.com>
Comment 28 Zhang Rui 2013-10-14 07:47:05 UTC
*** Bug 61741 has been marked as a duplicate of this bug. ***
Comment 29 Alex Markley 2013-11-01 14:43:52 UTC

I tested on a MacBookAir6,2 running kernel-3.12.0-0.rc7.git2.1.fc21.x86_64.

I can confirm that the speakers work now, but I am experiencing some strange volume issues and I'm not sure how to troubleshoot.

The trouble is this: When listening to music I am getting sudden volume dropouts if a second audio stream (like a notification sound) is played. Then, a second or so after the second audio stream is finished, the volume returns.

It's also REALLY loud. I have to have the volume turned most of the way down.

I realize this is incredibly untechnical information. However, I am more than willing to dig in and do some more useful troubleshooting if somebody can give me pointers.

Comment 30 Raymond 2013-11-02 08:33:04 UTC
headphone playback volume is using amp-out at node 0x10 which has different dB range with those amp-out at audio outputs nodes 0x02, 0x03, 0x04 and 0x05

you need to change the way which the driver to select out_vol_nid for cs4208

static hda_nid_t look_for_out_vol_nid(struct hda_codec *codec,
				      struct nid_path *path)
	int i;
+	if (codec->vendor_id == 0x10134208) {
+		for (i = 0; i < path->depth; i++) {
+			if (nid_has_volume(codec, path->path[i], HDA_OUTPUT))
+			return path->path[i];
+		}
+	}
+	else 
	for (i = path->depth - 1; i >= 0; i--) {
		if (nid_has_volume(codec, path->path[i], HDA_OUTPUT))
			return path->path[i];
	return 0;
Comment 31 Christoph 2013-11-02 17:32:29 UTC
Unfortunately I still experienced sporadically the 'no sound after hibernation problem' on a Macbook Air 6,2 (i5-4250U CPU @ 1.30GHz) with kernel 3.12.0 rc7. Please let me know if I can help you with some more details or experiments.
Comment 32 Raymond 2013-11-03 11:45:57 UTC
you have to post the working alsa-info and non working alsa-info and 

diff -u working-alsa-info non-working-alsa-info
Comment 33 Alex Markley 2013-11-03 19:01:04 UTC
(In reply to Christoph from comment #31)
> Unfortunately I still experienced sporadically the 'no sound after
> hibernation problem' on a Macbook Air 6,2 (i5-4250U CPU @ 1.30GHz) with
> kernel 3.12.0 rc7. Please let me know if I can help you with some more
> details or experiments.

Christoph, I'd be interested in trying to duplicate this issue over here. I have almost the same hardware. (Mine is the 13" with i7-4650U CPU @ 1.70GHz)

Based on Miek Gieben's earlier feedback, do you mean that sound isn't surviving a suspend/resume? (As opposed to a hibernate/thaw?)

Are you able to trigger the sound dropout with multiple sequential suspend/resume cycles? If so, what percentage of the time does it happen for you?
Comment 34 Alex Markley 2013-11-03 22:23:46 UTC
Created attachment 113201 [details]
Formatted patch from Comment #30


I created a patch based on Raymond's example in Comment #30. I applied it to 3.12-rc7 and tested on my machine.

The volume issue I was reporting appears to be gone. That is, the volume of a given audio stream stays steady as other streams (such as notification sounds) start and stop.

HOWEVER, I am now observing another problem, which is that there are short popping or cracking sounds when said notification sounds start and stop.

I suspended and resumed my machine several times and my sound came back upon resume without issue.

I also tested the other sound hardware. The headphone audio works fine, and plugging headphones in appropriately causes the speakers to be quiet. I also tested the built-in microphone and it appears to work well also.

So does anybody know what's causing the popping sound as audio streams start and stop? I've got my development environment set up so I can test patches now. :)

Comment 35 Christoph 2013-11-04 09:36:56 UTC
Sorry I didn't have any time check how many sequential hibernate/thaw cycles it takes to run into the bug on my machine.

All the negative experiences I had so far were coming from (S4-state), via pm-hibernate. Miek Gieben's comment about the race condition might be true for my setup as well: A shut down of the machine from KDE menue hangs, after running into the 'no sound state'. I have to push the power button to force the shutdown.

I just realized, that there is an issue in MAC OS 10.9, which is quite likely to be related: https://discussions.apple.com/thread/5482053?start=0&tstart=0
Comment 36 Takashi Iwai 2013-11-04 16:06:39 UTC
Thanks for spotting out.  Raymond's patch can't be taken as is, so I implemented a bit more generic way.  The patch is attached below.  Let me know if this works.

Regarding the S4 problem: try to get alsa-info.sh outputs before and after hibernation.  It might give us some hints.

Regarding the pop noise: the symptom sounds like a power-saving issue.  Does this happen even if you set /sys/module/snd_hda_intel/parameters/power_save=0?
(Note that the value might be changed on the fly by the system.)
Also, does the pop noise occur no matter which output (headphone / speaker) is used?

If the problem appears only with power_save, we need to put some muting, EAPD power down sequence, whatever before powering down the codec.
Comment 37 Takashi Iwai 2013-11-04 16:07:27 UTC
Created attachment 113281 [details]
Fix patch for invalid HP amp
Comment 38 Christoph 2013-11-04 16:33:15 UTC
Created attachment 113301 [details]
alsa-info: sound ok after initial boot
Comment 39 Christoph 2013-11-04 16:33:53 UTC
Created attachment 113311 [details]
alsa-info: no sound after fourth hibernate
Comment 40 Takashi Iwai 2013-11-04 16:45:04 UTC
The proc output is completely broken at no sound state, i.e. the codec doesn't respond properly at all.  At first, try to pass power_save_controller=0 option to snd-hda-intel module.  This will disable runtime PM of the controller chip.

If this doesn't help, try to set sync_write and allow_bus_reset like below.
This helped for some codecs in the past when the codec went crazy after resume.

--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -677,6 +677,9 @@ static int patch_cs4208(struct hda_codec *codec)
        codec->patch_ops = cs_patch_ops;
+       codec->bus->sync_write = 1;
+       codec->bus->allow_bus_reset = 1;
        snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PROBE);
        return 0;
Comment 41 Christoph 2013-11-04 17:00:40 UTC
I don't know if it is just random behavior on my machine, but in ~20 experiments I did so far I see that following behavior: 

I only run into the bug, when I stop all playback programs before triggering S4-state. 
When I start playback in vlc and keep it running, while triggering the S4-state, everything is fine after thaw.
Comment 42 Takashi Iwai 2013-11-04 17:10:10 UTC
Then it might be the runtime PM refcount unbalance, which has been fixed recently in the upstream (3.12).  Did you try 3.12 release kernel?

If that's the cause, power_save_controller=0 option should work around it.
Comment 43 Christoph 2013-11-04 17:12:01 UTC
Yeah you are right: 'power_save_controller=0' in snd-hda-intel seems to work for me. I didn't try the 3.12 release kernel so far. Do yo see a huge drawback in power consumption disabling it?
Comment 44 Takashi Iwai 2013-11-04 17:17:37 UTC
It won't be that much, I guess, since the codec is already powered off.

But it's still interesting whether it's really only about the unbalanced refcount, or the runtime PM is broken in general for Haswell.  So, please try 3.12 without the option.
Comment 45 Christoph 2013-11-04 17:31:55 UTC
Very nice, 3.12 release kernel works even with power_save_controller=1. Thank you very much for your advice Takashi!
Comment 46 Takashi Iwai 2013-11-04 17:34:14 UTC
Good to hear.  The fix commit for runtime PM was marked for stable kernels, so it'll be backported later to 3.11.x, too.

Thanks for quick tests.
Comment 47 Alex Markley 2013-11-05 16:47:04 UTC
(In reply to Takashi Iwai from comment #37)
> Created attachment 113281 [details]
> Fix patch for invalid HP amp

I applied this patch to 3.12 release and tested it on my MacBook Air.

(In reply to Takashi Iwai from comment #36)
> Regarding the pop noise: the symptom sounds like a power-saving issue.

With the above patch I am no longer able to reproduce the popping sounds!

Is it possible that Raymond's patch was hesitating too long in a time-sensitive portion of the code? Either way, I don't imagine power saving could have caused the problem, because the problem only occurred with 2 or more audio streams playing at the same time.

Now I am able to start and stop many concurrent streams of audio without experiencing any popping.

Thanks very much!
Comment 48 Takashi Iwai 2013-11-05 16:50:25 UTC
If 3.12 works, maybe the pop noise was due to the unbalanced runtime PM refcount.  The controller went down mistakenly at the time it shouldn't.

Just my $0.02.
Comment 49 Alex Markley 2013-11-05 20:01:42 UTC
So what kernel release is this bugfix expected to appear in? I'm not very familiar with the kernel dev cycle.
Comment 50 Raymond 2013-11-06 03:10:09 UTC
(In reply to Takashi Iwai from comment #37)
> Created attachment 113281 [details]
> Fix patch for invalid HP amp

so it is the virtual master volume require slaves with same stepsize to disable this amp, the vendor may have specific reason to implement this amp at the headphone pin complex

does this amp has better quality/snr with the amp at audio output ?
Comment 51 Takashi Iwai 2013-11-06 07:31:38 UTC
(In reply to Alex Markley from comment #49)
> So what kernel release is this bugfix expected to appear in? I'm not very
> familiar with the kernel dev cycle.

It'll be included in 3.13-rc1, and then will be backported to stable kernels.

(In reply to Raymond from comment #50)
> (In reply to Takashi Iwai from comment #37)
> > Created attachment 113281 [details]
> > Fix patch for invalid HP amp
> so it is the virtual master volume require slaves with same stepsize to
> disable this amp, the vendor may have specific reason to implement this amp
> at the headphone pin complex
> does this amp has better quality/snr with the amp at audio output ?

Unlikely.  DAC volume resolution is high enough, and the hp amp is also only attenuation, which would be applied on the top of DAC attenuation.

So, I think we can close the bug now.

Note You need to log in before you can comment on or make changes to this bug.