Headset microphone not recognized (combo jack in MBP 10.1)

bikto · November 16, 2016, 11:26pm

oldcpu:

Ok so what message do you get when you run the arecord ?ie when you open a konsole / xterm as a regular user and paste this in it:
arecord -vv -f S16_LE -c 2 -D hw:0,0 new.wav 
Talk in to the mic.

Post here ANY errors you may get.

To stop recording press <CTRL><C> in the konsole.

Then replay the file ‘new.wav’ that was created. Did it record any sound ?

Do you now have the boost adjusted ? Given you note you reset all your mixer settings its difficult to be certain the recommendation being provided is correct.

wrt the bug report you noted, it may or may not be relevant.

It is recording, but with the internal mic it sounds like I am in a car on the highway. (That is why I wanted to use the headset mic from the beginning)

arecord -vv -f S16_LE -c 2 -D hw:0,0 new1.wav
Aufnahme: WAVE ‘new1.wav’ : Signed 16 bit Little Endian, Rate: 8000 Hz, stereo
Hardware PCM card 0 ‘HDA Intel PCH’ device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 8000
exact rate : 8000 (8000/1)
msbits : 16
buffer_size : 4000
period_size : 1000
period_time : 125000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1000
period_event : 0
start_threshold : 1
stop_threshold : 4000
silence_threshold: 0
silence_size : 0
boundary : 9007199254740992000
appl_ptr : 0
hw_ptr : 0
###+ | 04%^C
Abbruch durch Signal Unterbrechung …

+ | 04%

I made also the knocknock-test. Knocking on the laptops speakers gives high pitch on the +++scale, knocking on the mic of the headset as far as possible away from the laptop gives almost no pitch. So it is definitely using the internal mic.
The mic boost can be set only to 0%, 50% or 100%. My test record was done with the 50% and 100% but if the voice gets louder on 100% equally the background noise gets louder. I like to focus on getting the headset mic to work, because during this test the internal fan was not even running and I expect the recording much worse, if it is turning.

deano_ferrari · November 17, 2016, 1:04am

It may well be that a bug report is required. FWIW, there is a diagnostic utility called ‘hdahacksensetest’ that can be used to help figure out if a chipset’s internal pins are working as expected. I accept that it could be daunting for a new user to make sense of, but it might help determine whether an external microphone is being detected at a hardware level or not.

It can be installed using

zypper hdajacksensetest

It gets used like this ‘hdajacksensetest -c X -d Y’

Application Options:
  -c, --card=X          card index (as can be seen in /proc/asound/cards)
  -d, --codec=Y         codec device index (as can be seen in /proc/asound/cardX/codecY)

For example

sudo hdajacksensetest -c 0 -d 0

The pin out put status should reflect whether given pins are connected/active or not. It may just help confirm that a bug report is required, or that there is a hardware issue.

Example post showing typical output when external headphones are plugged in or not…

Here’s an audio-debugging-techniques/ article written by David Henningson. It offers a technical insight into how this all fits together…

For Microphones – the only rule here is that if we have only one internal microphone and one external microphone, the external microphone takes over when you plug it in, and the internal microphone regains control when you unplug. Should there be any other inputs, e g two external mic jacks, or a line in jack, no autoswitching is done at the kernel level.

After this has been done, a signal is sent to userspace. Hopefully – this also varies between vendors. We’ll get back to that. What’s new in Ubuntu 11.10, is that this signal is being picked up by PulseAudio. This is important, because it enables PulseAudio, to switch port for volume control. So this means, when you press your media keys (or use the sound menu) to control your volume, you control your headphone’s volume when you have headphones plugged in, and your speakers’ volume when your headphones are unplugged.

So this not working properly, is one of the more common problems. I have written a small tool that helps you to debug whether this issue is in hardware or software. This tool is called “hda-jack-sense-test”. This program sends the “get pin sense” command to each codec and outputs the results. I actually had use for it earlier this week, and confirmed that it was a hardware issue: although the headphones were unplugged, the “get pin sense” command returned that the headphones were being plugged in and unplugged all the time.

If you can confirm that things are working at this level, you can also look in “Sound settings” to see if the port (this is known as a “connector”) is automatically switched whenever headphones – or microphone – is plugged in. If it is not, the most common cause is that kernel driver does not notify userspace correctly about that change.

oldcpu · November 17, 2016, 7:48am

To improve the internal mic, try backing off on the capture levels a small amount and see if that helps.

wrt the external mic, did you try any of the ‘model’ settings to force the alsa configuration upon boot ?


Cirrus Logic CS4206/4207
========================
  mbp55        MacBook Pro 5,5
  imac27       IMac 27 Inch
  auto        BIOS setup (default)

Do you need guidance on how to try those ?
.

bikto · November 17, 2016, 1:26pm

So I got the following:


#sudo hdajacksensetest -c 0 -d 0
root's password:
Pin 0x09 (Green Headphone): present = Yes
Pin 0x10 (White SPDIF Out): present = No

(Spooky, how does the computer know the headset is green? xD)
I checked for the proper device and codec, which had the same numbers like your example.

Is it a bug now? Where do I file this bug report? In bugzilla? Or somewhere at the alsa page?

did you try any of the ‘model’ settings to force the alsa configuration upon boot

Once I set the model to auto in yast with no good outcome, so i set it back to empty.
I will google around later about the model settings, as well as the debugging article.

oldcpu · November 17, 2016, 6:11pm

Auto is the default value. ie. by setting to auto all you did was apply what was already in place.

its the other two that need to be set and tested one at a time.

oldcpu · November 17, 2016, 6:17pm

If it does not work ‘out of the box’ (which I think is clearly the case after the possibility of a mixer misconfiguration is eliminated) then yes, it is a bug.

One should always write a bug report in openSUSE bugzilla. Writing one on alsa page is really just a duplicate, because at least one (and maybe two) of the SuSE-GmbH packagers of LEAP are alsa developers. There is guidance here for bug reports: openSUSE:Submitting bug reports - openSUSE Wiki

Attach to the bug report the output from sending the command (in an xterm/konsole):


/usr/sbin/alsa-info.sh --no-upload

Describe the problem in the bug report. Do not bother referencing this forum thread as the LEAP packagers will not read a forum page. Be certain you make it clear that your PC should have 2 mics and it is only showing the one (internal digital) that does not function well, and the external combined headset/mic does not work.

Every few days check the bug report and look for a reply. You will be asked questions. Answer them, do what ever test you are asked, and then be certain to clear any “NEED INFO” flag. Also, if you do not understand what you are asked to do, ask for clarification. Don’t waste your time surfing to figure out something that can be explained by the LEAP packagers in seconds.

Good luck.

deano_ferrari · November 17, 2016, 7:00pm

Good to know. It could be useful information in a bug report, along with your ‘alsa-info’ output.

(Spooky, how does the computer know the headset is green? xD)
I checked for the proper device and codec, which had the same numbers like your example.

The info comes from from the computer’s firmware, read from the “Pin Configuration Default" register, explained in the link I provided already. Sometimes a new quirk is required for a given codec to handle the physical configuration…

We also depend on information from the writers of BIOS/UEFI, i e the computer’s firmware. As a hardware designer, you have the freedom to choose which pins of the codec that go to what physical jack. You might decide that you want a digital out, or you decide that this machine should not have that functionality, and then you leave that pin unconnected.
Then the firmware engineer needs to know this, and program this into the codec when the computer boots. This is done by setting the “Pin Configuration Default” register. This register tells us not only the device type (headphone, mic, etc), but also the location (Internal, External, Docking Station), the color, and the channel mapping (to use for surround functionality).

Several years ago, we did not read this register much, but these days, we depend on that for all new computers for setting up the codec correctly. So what do we do if this register is wrong? Well, if we work with hardware pre-release, there might be a chance we can feed this information back to the firmware writers so they can correct the problem. If the hardware is already released, we have to create a “quirk”. This means that the driver overrides the firmware’s pin value(s) and instead uses its own value.