Bug 60811

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.

Created attachment 107353 [details]
Test patch

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.

Created attachment 107354 [details]
alsa-info output with test patch and model=mba42

Created attachment 107356 [details]
alsa-info output with test patch and no model option

Attached one without the model option, too.

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.

Just to confirm, I should check those without the test patch, right?

Yes.  The patch is obviously broken.

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

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.

OK, so the pins seems correctly assigned.  Then the rest is other adjustments like GPIO.  Did you try turn on/off each GPIO pin?

> Did you try turn on/off each GPIO pin?

I'm sorry, but where can I found documentation on how to do this?

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.

Setting GPIO0 the above way makes the speakers work. If you have a proper patch to test, please let me know.

The test fix patch is attached below.  Give it a try.

Created attachment 107811 [details]
Test fix patch

Works, thank you :) Feel free to add:

Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org>

Indeed works \o/ However if I now plugin my headset, the speaker's audio isn't muted.

Created attachment 108341 [details]
Cirrus Logic inf

Hello,

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.

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.

Patch from comment #20 works like a charm (tested on 3.12-rc1)

Hmmm 3.12-rc: doesn't survive a resume though... :-( No audio at all, neither headphones, nor speakers.

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

Re: 3.12-rc1: I cannot reproduce it anymore. The audio keeps on working after a resume. Strange.

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.

Great.  Ben, could you give your sign-off for the patch so that I can merge to the upstream?

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>

*** Bug 61741 has been marked as a duplicate of this bug. ***

All,

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.

Thanks,

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;
}

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.

you have to post the working alsa-info and non working alsa-info and 


diff -u working-alsa-info non-working-alsa-info

(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?

Created attachment 113201 [details]
Formatted patch from Comment #30

All,

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

Thanks!

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

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.

Created attachment 113281 [details]
Fix patch for invalid HP amp

Created attachment 113301 [details]
alsa-info: sound ok after initial boot

Created attachment 113311 [details]
alsa-info: no sound after fourth hibernate

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;

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.

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.

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?

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.

Very nice, 3.12 release kernel works even with power_save_controller=1. Thank you very much for your advice Takashi!

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.

(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!

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.

So what kernel release is this bugfix expected to appear in? I'm not very familiar with the kernel dev cycle.

(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 ?

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