Bug 116051

Summary: Internal microphone and line in do not work at all in a Macbook Pro 8,2
Product: Drivers Reporter: Fernando (fmuro)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: NEW ---    
Severity: normal CC: superquad.vortex2, tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.4.0-15-generic Subsystem:
Regression: No Bisected commit-id:
Attachments: alsa-info.sh with mbp81 kernel 4.4.6
physical I/Os
alsa-info.sh with mbp81 kernel 4.4.6 while recording in audacity from internal micro
alsa-info.sh with mbp81 kernel 4.4.6 while recording in audacity from line in
Kernel 4.4.6 recording with audacity with the analog internal microphone
Kernel 4.4.6 recording with audacity with the analog line in
Kernel 4.4.6 recording with arecord with the analog internal microphone

Description Fernando 2016-04-08 10:13:15 UTC
As the summary says, no input is detected in either channel. I've checked with audacity. The output of alsa-info.sh can be found in

http://www.alsa-project.org/db/?f=6e527b16e428d4bb42498bef6affee280e098f3c

I first filed this as an ubuntu bug (this happened to me in Xenial beta2). The link is here, in case it helps:

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

Raymond, which was very helpful there, suggested that I should file a bug here. He also said, looking at the previous output, that "You have line in jack and internal mic, but power setting are D3 instead of D0."

Following Raymond's indications, I also tried a couple of things from the following report to no avail:

https://bugzilla.kernel.org/show_bug.cgi?id=50781

However this report helped me to get the left channel of the internal microphone working in Wily (kernel 4.2.0-35-generic). Previously only the right channel was working. Line in doesn't work in Wily, but I'm not that worried about this since I'm happy with only the internal micro and Wily is close to die. But I'd be very much interested in getting this working in recent kernels, precisely because Wily is dying.
Comment 1 Takashi Iwai 2016-04-08 10:35:29 UTC
First off, you should try a newer kernel, at least, 4.4.x stable kernel, not 4.4.0.

Then try to pass model=mbp81 option to snd-hda-intel module.
Comment 2 Fernando 2016-04-08 11:19:16 UTC
Same result in 4.4.4 with mpb81. I'll now test 4.4.6 and report.
Comment 3 Fernando 2016-04-08 11:34:41 UTC
... and again the same with 4.4.6 and 4.5.0, with and without options snd_hda_intel index=0 model=mbp81.
Comment 4 Takashi Iwai 2016-04-08 12:27:24 UTC
Give the alsa-info.sh output with the model option applied.
Comment 5 Takashi Iwai 2016-04-08 12:36:10 UTC
And, what physical I/Os does the machine have?  It has a built-in speaker, a built-in mic, a headphone jack, and what else?
Comment 6 Takashi Iwai 2016-04-08 13:26:46 UTC
In anyway, run alsa-info.sh during recording on the built-in mic.  Also, if you have an external mic, plug it, and again take alsa-info.sh output during recording from mic-in jack.

At best, run the script with --no-upload option, and attach (don't paste) the outputs to this bugzilla.
Comment 7 Fernando 2016-04-08 13:38:34 UTC
Created attachment 212171 [details]
alsa-info.sh with mbp81 kernel 4.4.6
Comment 8 Fernando 2016-04-08 13:41:10 UTC
Created attachment 212181 [details]
physical I/Os

A screenshot from OS X. I'm not familiar with technical details, so I think this will be the best way for you to see what I have.
Comment 9 Fernando 2016-04-08 13:44:14 UTC
Created attachment 212191 [details]
alsa-info.sh with mbp81 kernel 4.4.6 while recording in audacity from internal micro
Comment 10 Fernando 2016-04-08 13:44:38 UTC
Created attachment 212201 [details]
alsa-info.sh with mbp81 kernel 4.4.6 while recording in audacity from line in
Comment 11 Fernando 2016-04-08 13:45:39 UTC
Hi Takashi, I've uploaded four files answering your previous three posts. Thanks a lot for the effort you're taking in helping.
Comment 12 Takashi Iwai 2016-04-08 13:50:49 UTC
How did you record?  Judging from alsa-info.sh output, it seems that you recorded from the digital input, not from the analog input, by some reason.

For example, try to record via
  % arecord -vv -Dplughw:0,0 -fdat foo.wav
Comment 13 Fernando 2016-04-08 14:25:42 UTC
It's all very strange. I tried to record with audacity. There was no analog recording option in audacity! But after rebooting, with 4.4.6 and 4.4.2, sometimes I've got a single analog option (not specifying whether internal mic or line in) and sometimes both options. I'll upload now three files. Two of them recoding with audacity, with internal mic and line in. The third one is with arecord, which produced a 0:00 file and an error message: 

arecord: pcm_read:2031: read error: Input/output error
Comment 14 Fernando 2016-04-08 14:26:35 UTC
Created attachment 212221 [details]
Kernel 4.4.6 recording with audacity with the analog internal microphone
Comment 15 Fernando 2016-04-08 14:27:23 UTC
Created attachment 212231 [details]
Kernel 4.4.6 recording with audacity with the analog line in
Comment 16 Fernando 2016-04-08 14:27:54 UTC
Created attachment 212241 [details]
Kernel 4.4.6 recording with arecord with the analog internal microphone
Comment 17 Fernando 2016-04-08 14:28:54 UTC
Where I've said 4.4.2 above it actually was 4.4.4.
Comment 18 Takashi Iwai 2016-04-08 14:38:55 UTC
Maybe we should start with a safer mode.  Change cs_alloc_spec() in sound/pci/hda/patch_cirrus.c from
  codec->power_save_node = 1;
to
  codec->power_save_node = 0;
Comment 19 Fernando 2016-04-08 14:48:44 UTC
Should I reboot after this change or it is enough to alsa reload?
Comment 20 Raymond 2016-04-08 14:52:05 UTC
It is strange that digital audio input has stream tag but analog audio input does not

The avail subdevice of analog capture is zero but digital capture is one
Comment 21 Raymond 2016-04-08 14:54:53 UTC
You can use hdajackretask to change digital input pin complex as not connected
Comment 22 Takashi Iwai 2016-04-08 14:58:43 UTC
(In reply to Fernando from comment #19)
> Should I reboot after this change or it is enough to alsa reload?

Reload should be enough, but a clean reboot might be safer.
When modifying and rebuilding the kernel module, it'd be good to put some printk() to indicate that you're certainly booting the modified kernel code.
One of the most often failures is the wrong installation and testing.
Comment 23 Fernando 2016-04-08 15:21:18 UTC
Takashi, Raymond, I'm going to need some help on how to do this. Where can I find patch_cirrus.c? I've tried to no avail. When I find it and change power_save_node, how can I rebuild the kernel module? Where should I put printk()? I've spent a while looking all this up in google, with little success.
Comment 24 Raymond 2016-04-08 16:16:39 UTC
Node 0x0f [Pin Complex] wcaps 0x410681: Stereo Digital 
Pincap 0x00000024: IN Detect 
Pin Default 0x00cbe030: [Jack] SPDIF In at Ext N/A Conn = Comb, Color = White DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x20: IN 
Unsolicited: tag=07, enabled=1 
Power states: D0 D3 EPSS 
Power: setting=D3, actual=D3 Delay: 1 samples

The driver create spdif in jack and enable unsolicited event for SPDIF in 

control.27 { iface CARD name 'SPDIF Phantom Jack' value true comment { access read type BOOLEAN count 1 } } 

control.28 { iface CARD name 'SPDIF In Jack' value false comment { access read type BOOLEAN count 1 } }
Comment 25 Fernando 2016-04-08 23:54:51 UTC
OK, I've been doing some research, have downloaded the kernel 4.4.6 sources, have compiled the modules in sound/pci/hda, have unloaded the modules, then loaded the modules with sudo insmod *.ko (and also a hello world module), have run sudo alsa reload, and the mic still doesn't work.
Comment 26 Raymond 2016-04-09 06:58:09 UTC
	control.8 {
		iface MIXER
		name 'Capture Source'
		value Line
		comment {
			access 'read write'
			type ENUMERATED
			count 1
			item.0 Mic
			item.1 Line
		}
	}

did you switch capture source before you start recording since auto line in switch is disabled by default , seem dynamic adc switch not occur

stream tag pf audio input should be one instead of zero when analog capture device  open



Node 0x05 [Audio Input] wcaps 0x18051b: Stereo Amp-In
  Device: name="CS4206 Analog", type="Audio", device=0
  Amp-In caps: ofs=0x33, nsteps=0x3f, stepsize=0x03, mute=1
  Amp-In vals:  [0x3f 0x3f]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
    rates [0x1f5]: 8000 16000 32000 44100 48000 88200 96000
    bits [0x1e]: 16 20 24 32
    formats [0x3]: PCM FLOAT
  Power states:  D0 D3 EPSS
  Power: setting=D3, actual=D0
  Delay: 8 samples
  Connection: 2
     0x0c* 0x12
Node 0x06 [Audio Input] wcaps 0x18051b: Stereo Amp-In
  Control: name="Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Capture Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x33, nsteps=0x3f, stepsize=0x03, mute=1
  Amp-In vals:  [0x3f 0x3f]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
    rates [0x1f5]: 8000 16000 32000 44100 48000 88200 96000
    bits [0x1e]: 16 20 24 32
    formats [0x3]: PCM FLOAT
  Power states:  D0 D3 EPSS
  Power: setting=D3, actual=D0
  Delay: 8 samples
  Connection: 2
     0x0d* 0x0e
Node 0x07 [Audio Input] wcaps 0x180791: Stereo Digital
  Control: name="IEC958 Capture Switch", index=0, device=0
  Control: name="IEC958 Capture Default", index=0, device=0
  Device: name="CS4206 Digital", type="SPDIF", device=1
  Converter: stream=2, channel=0
  SDI-Select: 0
  Digital: Preemphasis Non-Copyright
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x570]: 32000 44100 48000 96000 192000
    bits [0x1e]: 16 20 24 32
    formats [0x7]: PCM FLOAT AC3
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Delay: 8 samples
  Connection: 1
     0x0f

why digital input still has stream=2 when digital capture device is closed


ARECORD

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

!!Amixer output
Comment 27 Raymond 2016-04-09 07:21:24 UTC
your line in {0x0c) and internal mic (0xd)are connected to two different ADC 0x5 and 0x6,  capture source need to be write protected if dnyamic adc switching between node 0x05 and node 0x6 not enabled
Comment 28 Fernando 2016-04-09 09:52:02 UTC
(In reply to Takashi Iwai from comment #18)
> Maybe we should start with a safer mode.  Change cs_alloc_spec() in
> sound/pci/hda/patch_cirrus.c from
>   codec->power_save_node = 1;
> to
>   codec->power_save_node = 0;

OK, let me tell you what I've done because I think something went wrong.

I'm running kernel 4.4.6.

1) Download kernel 4.4.6 and extract in ~.

2) Go to ~/linux-4.4.6 and execute:
   $ make oldconfig
   $ make prepare
   $ make scripts

3) Move to ~/linux-4.4.6/sound/pci/hda and run:
   $ make -C /lib/modules/4.4.6-040406-generic/build M=$(pwd) modules
   $ sudo make -C /lib/modules/4.4.6-040406-generic/build M=$(pwd) modules_install

Then I got the following error, once for every module in the folder (I just copy one here):

INSTALL /home/fernando/linux-4.4.6/sound/pci/hda/snd-hda-intel.ko
At main.c:222:
- SSL error:02001002:system library:fopen:No such file or directory: bss_file.c:168
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:171
sign-file: certs/signing_key.pem: No such file or directory


It's here where I made: sudo insmod *.ko

This isn't correct, is it?
Comment 29 Fernando 2016-04-09 15:02:29 UTC
(In reply to Raymond from comment #26)
>       control.8 {
>               iface MIXER
>               name 'Capture Source'
>               value Line
>               comment {
>                       access 'read write'
>                       type ENUMERATED
>                       count 1
>                       item.0 Mic
>                       item.1 Line
>               }
>       }
> 
> did you switch capture source before you start recording since auto line in
> switch is disabled by default , seem dynamic adc switch not occur

In the logs where the word analog appears explicitly, I took special care of selecting the analog input in audacity before starting recording. In the ALSA configuration module, analog was also always selected.

> 
> stream tag pf audio input should be one instead of zero when analog capture
> device  Owen

Could it be that for some reason the kernel insists in recording from digital?

> 
> 
> 
> Node 0x05 [Audio Input] wcaps 0x18051b: Stereo Amp-In
>   Device: name="CS4206 Analog", type="Audio", device=0
>   Amp-In caps: ofs=0x33, nsteps=0x3f, stepsize=0x03, mute=1
>   Amp-In vals:  [0x3f 0x3f]
>   Converter: stream=0, channel=0
>   SDI-Select: 0
>   PCM:
>     rates [0x1f5]: 8000 16000 32000 44100 48000 88200 96000
>     bits [0x1e]: 16 20 24 32
>     formats [0x3]: PCM FLOAT
>   Power states:  D0 D3 EPSS
>   Power: setting=D3, actual=D0
>   Delay: 8 samples
>   Connection: 2
>      0x0c* 0x12
> Node 0x06 [Audio Input] wcaps 0x18051b: Stereo Amp-In
>   Control: name="Capture Volume", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>   Control: name="Capture Switch", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>   Amp-In caps: ofs=0x33, nsteps=0x3f, stepsize=0x03, mute=1
>   Amp-In vals:  [0x3f 0x3f]
>   Converter: stream=0, channel=0
>   SDI-Select: 0
>   PCM:
>     rates [0x1f5]: 8000 16000 32000 44100 48000 88200 96000
>     bits [0x1e]: 16 20 24 32
>     formats [0x3]: PCM FLOAT
>   Power states:  D0 D3 EPSS
>   Power: setting=D3, actual=D0
>   Delay: 8 samples
>   Connection: 2
>      0x0d* 0x0e
> Node 0x07 [Audio Input] wcaps 0x180791: Stereo Digital
>   Control: name="IEC958 Capture Switch", index=0, device=0
>   Control: name="IEC958 Capture Default", index=0, device=0
>   Device: name="CS4206 Digital", type="SPDIF", device=1
>   Converter: stream=2, channel=0
>   SDI-Select: 0
>   Digital: Preemphasis Non-Copyright
>   Digital category: 0x0
>   IEC Coding Type: 0x0
>   PCM:
>     rates [0x570]: 32000 44100 48000 96000 192000
>     bits [0x1e]: 16 20 24 32
>     formats [0x7]: PCM FLOAT AC3
>   Unsolicited: tag=00, enabled=0
>   Power states:  D0 D3 EPSS
>   Power: setting=D0, actual=D0
>   Delay: 8 samples
>   Connection: 1
>      0x0f
> 
> why digital input still has stream=2 when digital capture device is closed
> 
> 
> ARECORD
> 
> **** List of CAPTURE Hardware Devices ****
> card 0: PCH [HDA Intel PCH], device 0: CS4206 Analog [CS4206 Analog]
>   Subdevices: 0/1
>   Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 1: CS4206 Digital [CS4206 Digital]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> 
> !!Amixer output
Comment 30 Raymond 2016-04-09 15:29:04 UTC
only one of audio input 0x05 or 0x06 should has

 Converter: stream=1, channel=0

when you are recording but not both 


using hda-emu , switch capture source won't stop the running adc input and start the selected adc


you can use hdajackretask to 

1) set pin default of both 0x0c line in and node 0x0f SPDIF in 

Pin Default 0x400000f0: [N/A] 

to test only internal mic 0xd


2) set pin default of both 0x0d mic and node 0x0f SPDIF in

Pin Default 0x400000f0: [N/A] 

to test only line in
Comment 31 Raymond 2016-04-09 15:40:55 UTC
https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/profile-sets/default.conf

most likely it is pulseaudio probe SPDIF In 


[Mapping iec958-stereo]
device-strings = iec958:%f
channel-map = left,right
paths-input = iec958-stereo-input
paths-output = iec958-stereo-output
priority = 5
Comment 32 Fernando 2016-04-09 23:35:24 UTC
New discovery, when coming back from suspend, the internal microphone works and I can record with arecord. The behaviour of audacity is a little bit strangle. Most of the times, when I open it, even if the internal microphone was working before, it stops working. With audacity open, after suspending and coming back, I can record.
Comment 33 Fernando 2016-04-09 23:49:36 UTC
(In reply to Raymond from comment #30)
> only one of audio input 0x05 or 0x06 should has
> 
>  Converter: stream=1, channel=0
> 
> when you are recording but not both 
> 
> 
> using hda-emu , switch capture source won't stop the running adc input and
> start the selected adc
> 
> 
> you can use hdajackretask to 
> 
> 1) set pin default of both 0x0c line in and node 0x0f SPDIF in 
> 
> Pin Default 0x400000f0: [N/A] 
> 
> to test only internal mic 0xd

Setting 0x0c and 0x0f to not connected with hdajackretask, after rebooting the internal microphone works. I can't test line in now, I'm travelling, I'll try to borrow one tomorrow in this hotel.

> 
> 
> 2) set pin default of both 0x0d mic and node 0x0f SPDIF in
> 
> Pin Default 0x400000f0: [N/A] 
> 
> to test only line in
Comment 34 Raymond 2016-04-10 03:53:24 UTC
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_cirrus.c?id=1077a024812d3b2d76a7a371df75795a276d9dd8



In previous version, it can change adc when select different input

-
-static int change_cur_input(struct hda_codec *codec, unsigned int idx,
-			    int force)
-{
-	struct cs_spec *spec = codec->spec;
-	
-	if (spec->cur_input == idx && !force)
-		return 0;
-	if (spec->cur_adc && spec->cur_adc != spec->adc_nid[idx]) {
-		/* stream is running, let's swap the current ADC */
-		__snd_hda_codec_cleanup_stream(codec, spec->cur_adc, 1);
-		spec->cur_adc = spec->adc_nid[idx];
-		snd_hda_codec_setup_stream(codec, spec->cur_adc,
-					   spec->cur_adc_stream_tag, 0,
-					   spec->cur_adc_format);
-	}
-	spec->cur_input = idx;
-	cs_update_input_select(codec);
-	return 1;
-}
-
Comment 35 Fernando 2016-04-13 13:05:42 UTC
Maybe I haven't understood well some of your comments. Is there anything I can still do to get this fixed, apart from the workaround of disabling 0x0c and 0x0f? Will it be fixed in a near future? I'm really willing to help to get this fixed, for the convenience of all users of MBP8,2 and similar computers. Thanks!
Comment 36 Raymond 2016-04-14 02:38:35 UTC
https://bugzilla.kernel.org/show_bug.cgi?id=116171

Do your line in work or not?


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_cirrus.c?id=bad994f5b4ab57eec8d56c180edca00505c3eeb2

If cs420x use single_adc_amp, do the amp of two adc changed at the same time even when th unused adc is powered down?
Comment 37 Fernando 2016-04-19 15:08:38 UTC
(In reply to Raymond from comment #36)
> https://bugzilla.kernel.org/show_bug.cgi?id=116171
> 
> Do your line in work or not?

Sorry for answering kind of late. I couldn't find a microphone in my holiday place. I'm back and I've tested what you suggested, but the line in doesn't work. Actually, if I just disable SPDIF and reboot, the internal microphone works, but as long as I plug and unplug a microphone in the line, the internal one stops working until I reboot. So currently I've disabled the SPDIF in and the line in, in order to get at least the internan micro working, which is kind of enough to communicate with colleagues and family. 

> 
> 
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/
> pci/hda/patch_cirrus.c?id=bad994f5b4ab57eec8d56c180edca00505c3eeb2
> 
> If cs420x use single_adc_amp, do the amp of two adc changed at the same time
> even when th unused adc is powered down?

How could I check this?
Comment 38 Takashi Iwai 2016-04-19 15:18:25 UTC
The breakage of line-in switching is a known issue and tracked in bug#116171.
It's likely the inconsistent power state handling by cirrus codec chip.
Two fix patches are found in the bug entry above.
Comment 39 Fernando 2016-04-26 14:55:12 UTC
Thanks, Takashi. As I understand, these two patches for the line in will eventually be backported to the 4.4 kernel, so I'll wait for that functionality, which I don't use that much actually. Concerning the internal microphone. Will there be any patch so that I can also get rid of my current overrides in the future?
Comment 40 Raymond 2016-04-27 02:11:35 UTC
why there is no dig_capture_pcm_open, dig_capture_pcm_prepare, dig_capture_pcm_close and dig_capture_pcm_cleanup in pcm_dig_capture ?

static const struct hda_pcm_stream pcm_digital_capture = {
	.substreams = 1,
	.channels_min = 2,
	.channels_max = 2,
	/* NID is set in build_pcms */
};
Comment 41 Raymond 2016-04-27 02:13:24 UTC
do your macbook pro 8,2 really have SPDIF input ?
Comment 42 Fernando 2016-04-27 09:14:42 UTC
(In reply to Raymond from comment #41)
> do your macbook pro 8,2 really have SPDIF input ?

I think so, but just because it's in the specifications.