Bug 201989
Created attachment 280005 [details]
amixer when the bit 0 of Misc field is set
Created attachment 280007 [details]
amixer when the bit 0 of Misc field is unset
I compare the amixer outputs between unset and set bit 0 of Misc field: Simple mixer control 'Headset Mic',0 - Capabilities: pvolume pswitch + Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive + Capture exclusive group: 0 Playback channels: Front Left - Front Right + Capture channels: Mono Limits: Playback 0 - 31 - Mono: + Mono: Capture [on] Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Headset Mic Boost',0 @@ -52,6 +54,11 @@ Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] +Simple mixer control 'Internal Mic',0 + Capabilities: cswitch cswitch-joined cswitch-exclusive + Capture exclusive group: 0 + Capture channels: Mono + Mono: Capture [off] Simple mixer control 'Internal Mic Boost',0 Capabilities: volume Playback channels: Front Left - Front Right If the bit is set, system gets "Simple mixer control 'Internal Mic'". If the bit is unset, system does not get 'Internal Mic' control. Created attachment 280011 [details]
pactl when the bit 0 of Misc field is set
Created attachment 280013 [details]
pactl when the bit 0 of Misc field is unset
According to attachment 280011 [details] and attachment 280013 [details], PulseAudio can see both analog-input-internal-mic and analog-input-headset-mic either the bit 0 of Misc field is set or unset when the headset is plugged. Created attachment 280015 [details]
Fix the mic control when headset is plugged
This patch makes system get sound from headset's mic and internal mic correctly with proper setting when the headset is plugged.
- If the internal mic is chosen, system only gets sound from internal mic.
- If the headset's mic is chosen, system only gets sound from headset's mic.
Created attachment 280017 [details] amixer's report with bit 0 of Misc field is unset after apply the patch After apply the patch attachment 280015 [details], system gets "Simple mixer control 'Internal Mic'" whether the headset mic is auto detection or not. Is this the result of the unmodified driver as is? It's already strange that the driver assigns "Capture Source" even if it's in auto-mic mode. They contradict with each other. I quickly checked hda-emu with the given alsa-info.sh, but no such behavior is seen. What did you do exactly...? Created attachment 280045 [details] alsa-info with original kernel (In reply to Takashi Iwai from comment #9) > Is this the result of the unmodified driver as is? This alsa-info (as the attachment) comes without any fix, changes ... in the kernel Created attachment 280047 [details] alsa-info with the headset mic's pin quirk, bit 0 of the Misc field is unset (In reply to Takashi Iwai from comment #9) > What did you do exactly...? I have done 2 steps. Step 1: Add a quirk to enable the headset mic of the Acer AIO desktop diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 129ebd857892..e06825537c59 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5582,6 +5582,7 @@ enum { ALC294_FIXUP_ASUS_HEADSET_MIC, ALC294_FIXUP_ASUS_SPK, ALC225_FIXUP_HEADSET_JACK, + ALC269VC_FIXUP_ACER_HEADSET_MIC, }; static const struct hda_fixup alc269_fixups[] = { @@ -6522,6 +6523,15 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_jack, }, + [ALC269VC_FIXUP_ACER_HEADSET_MIC] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x18, 0x02a11030 }, /* use as headset mic, without its own jack detect */ + { } + }, + .chained = true, + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6537,6 +6547,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820", ALC269VC_FIXUP_ACER_HEADSET_MIC), SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", ALC283_FIXUP_CHROME_BOOK), SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), Now, the headset mic can get sound. This alsa-info (as the attachment) comes with the pin quirk. Setting and clearing the bit 0 of the Misc field make different behavior as comment #3. But PulseAudio always sees both analog-input-internal-mic and analog-input-headset-mic as comment #6. Now, I hit the issue: When the headset is plugged, I choose the internal mic as the input source, but system only gets sound from headset's mic. Created attachment 280049 [details] alsa-info with the headset mic's pin quirk, bit 0 of the Misc field is unset and applied attachment 280015 [details] (In reply to Takashi Iwai from comment #9) > What did you do exactly...? Step 2: Fix the mic control when headset is plugged Apply the patch attachment 280015 [details]. Now, the headset mic can get sound. And "Simple mixer control 'Internal Mic'" is listed on the section - Amixer output of alsa-info as the attachment. - If the internal mic is chosen, system only gets sound from internal mic. - If the headset's mic is chosen, system only gets sound from headset's mic. Created attachment 280067 [details] alsa-info for code tracing without patch attachment 280015 [details] I add some debug message for tracing the code path: diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index a1a8669ac5ed..8d6eaf5c1c9d 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -82,6 +82,7 @@ snd_hda_gen_add_kctl(struct hda_gen_spec *spec, const char *name, knew->name = kstrdup(knew->name, GFP_KERNEL); if (!knew->name) return NULL; + pr_warn("%s: knew->name=%s\n", __func__, knew->name); return knew; } EXPORT_SYMBOL_GPL(snd_hda_gen_add_kctl); @@ -3368,6 +3369,7 @@ static int create_input_ctls(struct hda_codec *codec) if (err < 0) return err; } + codec_warn(codec, "%s: spec->input_labels[%d]=%s\n", __func__, i, spec->input_labels[i]); } /* add stereo mix when explicitly enabled via hint */ @@ -5220,6 +5222,7 @@ int snd_hda_gen_build_controls(struct hda_codec *codec) int err; if (spec->kctls.used) { + codec_warn(codec, "%s: kctls are used\n", __func__); err = snd_hda_add_new_ctls(codec, spec->kctls.list); if (err < 0) return err; diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 129ebd857892..48bb5ae499f0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5582,6 +5582,7 @@ enum { ALC294_FIXUP_ASUS_HEADSET_MIC, ALC294_FIXUP_ASUS_SPK, ALC225_FIXUP_HEADSET_JACK, + ALC269VC_FIXUP_ACER_HEADSET_MIC, }; static const struct hda_fixup alc269_fixups[] = { @@ -6522,6 +6523,15 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_jack, }, + [ALC269VC_FIXUP_ACER_HEADSET_MIC] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x18, 0x02a11030 }, /* use as headset mic, without its own jack detect */ + { } + }, + .chained = true, + .chain_id = ALC269_FIXUP_HEADSET_MODE + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6537,6 +6547,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820", ALC269VC_FIXUP_ACER_HEADSET_MIC), SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", ALC283_FIXUP_CHROME_BOOK), SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE), I got the log: [ 11.359266] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops 0xffffffff8349f440) [ 11.427242] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VC: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 11.427246] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 11.427249] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 11.427251] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 11.427252] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 11.427255] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x18 [ 11.427257] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 [ 11.430597] snd_hda_gen_add_kctl: knew->name=Headphone Playback Volume [ 11.430601] snd_hda_gen_add_kctl: knew->name=Headphone Playback Switch [ 11.430603] snd_hda_gen_add_kctl: knew->name=Speaker Playback Volume [ 11.430604] snd_hda_gen_add_kctl: knew->name=Speaker Playback Switch [ 11.430606] snd_hda_gen_add_kctl: knew->name=Loopback Mixing [ 11.430901] snd_hda_gen_add_kctl: knew->name=Headset Mic Playback Volume [ 11.430903] snd_hda_gen_add_kctl: knew->name=Headset Mic Playback Switch [ 11.433408] snd_hda_codec_realtek hdaudioC0D0: create_input_ctls: spec->input_labels[0]=Headset Mic [ 11.433573] snd_hda_codec_realtek hdaudioC0D0: create_input_ctls: spec->input_labels[1]=Internal Mic [ 11.435075] snd_hda_gen_add_kctl: knew->name=Auto-Mute Mode [ 11.435400] snd_hda_gen_add_kctl: knew->name=Capture Volume [ 11.435402] snd_hda_gen_add_kctl: knew->name=Capture Switch [ 11.435406] snd_hda_gen_add_kctl: knew->name=Headset Mic Boost Volume [ 11.435408] snd_hda_gen_add_kctl: knew->name=Internal Mic Boost Volume Created attachment 280069 [details] alsa-info for code tracing with patch attachment 280015 [details] The same debug message as Comment #13 for tracing the code path. I got the log: [ 11.666390] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VC: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 11.666393] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 11.666396] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 11.666397] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 11.666399] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 11.666402] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x18 [ 11.666404] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 [ 11.669732] snd_hda_gen_add_kctl: knew->name=Headphone Playback Volume [ 11.669735] snd_hda_gen_add_kctl: knew->name=Headphone Playback Switch [ 11.669737] snd_hda_gen_add_kctl: knew->name=Speaker Playback Volume [ 11.669738] snd_hda_gen_add_kctl: knew->name=Speaker Playback Switch [ 11.669740] snd_hda_gen_add_kctl: knew->name=Loopback Mixing [ 11.670051] snd_hda_gen_add_kctl: knew->name=Headset Mic Playback Volume [ 11.670052] snd_hda_gen_add_kctl: knew->name=Headset Mic Playback Switch [ 11.672385] snd_hda_codec_realtek hdaudioC0D0: create_input_ctls: spec->input_labels[0]=Headset Mic [ 11.672550] snd_hda_codec_realtek hdaudioC0D0: create_input_ctls: spec->input_labels[1]=Internal Mic [ 11.674057] snd_hda_gen_add_kctl: knew->name=Auto-Mute Mode [ 11.674062] snd_hda_gen_add_kctl: knew->name=Capture Source [ 11.674386] snd_hda_gen_add_kctl: knew->name=Capture Volume [ 11.674387] snd_hda_gen_add_kctl: knew->name=Capture Switch [ 11.674390] snd_hda_gen_add_kctl: knew->name=Headset Mic Boost Volume [ 11.674392] snd_hda_gen_add_kctl: knew->name=Internal Mic Boost Volume The "snd_hda_gen_add_kctl: knew->name=Capture Source" appears. According to Comment #13 and Comment #14, the "Capture Source" mux is indeed what creates the Internal Mic mixer control. "Headset Mic" is visible in amixer in both cases since it additionally is composed of the "Headset Mic Playback Volume" and "Headset Mic Playback Switch" controls created by the code examined above. That then potentially indicates that in auto mic mode, the mux controls to change the capture source are not available to userspace. Is this by design or is it a bug? (In reply to jian-hong from comment #15) > According to Comment #13 and Comment #14, the "Capture Source" mux is indeed > what creates the Internal Mic mixer control. "Headset Mic" is visible in > amixer in both cases since it additionally is composed of the "Headset Mic > Playback Volume" and "Headset Mic Playback Switch" controls created by the > code examined above. You are likely looking at a wrong point. These "Headset Mic" controls are only for playback direction and have nothing to do with the capture. That is, these are only for analog-loopback volumes, and don't influence on the capture stream. If they really matter for PA, it means a bug of PA. But I guess it's something else. (In reply to Takashi Iwai from comment #16) > You are likely looking at a wrong point. > These "Headset Mic" controls are only for playback direction and have > nothing to do with the capture. That is, these are only for analog-loopback > volumes, and don't influence on the capture stream. > > If they really matter for PA, it means a bug of PA. But I guess it's > something else. Is there anything else we can help for this issue? Hmm, could you help us clarify our understanding more so that we can continue investigating?
Here is the situation plus our working theory so far in a bit more detail - please point out what we are missing.
We are adding a pin quirk for this new hardware marking pin 0x18 as a headset jack (the codec default has it marked as unavailable). We also add ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC to activate HDA_PINCFG_HEADSET_MIC. The system also has an internal mic which does not need quirking.
In the pin quirk, if we mark the pin as NOT capable of presence detection, we see the following:
1. Via regular parsing code, snd_hda_gen_add_kctl is called for "Headset Mic Playback Volume" and "Headset Mic Playback Switch". This creates a mixer control described by amixer named "Headset Mic" with capabilities: pvolume pswitch
2. create_capture_mixers() is called, and calls snd_hda_gen_add_kctl() to create an input source selection mux called "Capture Source". There is no such element with this name listed by amixer, however the effect of this call is:
a) It modifies the "Headset Mic" control created above to additionally add capabilities "cswitch cswitch-joined cswitch-exclusive" to form the cumulative capability string of "pvolume pswitch cswitch cswitch-joined cswitch-exclusive"
b) It causes the creation of a new amixer control named "Internal Mic" with capabilities "cswitch cswitch-joined cswitch-exclusive"
3. pulseaudio and other userspace agents now have the capability of choosing which mic is active - Internal Mic or Headset Mic - by nature of the cswitch controls. Input device selection works in the regular GNOME UI.
We don't see anything unexpected/unusual so far there, but it is not ideal to have disabled the headset mic presence detection when we have confirmed that it is active on Windows, plus the pinsense verb returns correct results on Linux too.
So now moving on to the problem case: we modify the pin quirk above to mark the headset jack as capable of presence detection.
This activates the kernel's auto_mic functionality, so step 2 above is skipped due to the surrounding condition "if (!spec->auto_mic && imux->num_items > 1)".
Since step 2 was skipped, no cswitch controls are created for Internal Mic / Headset Mic so pulseaudio and other userspace agents have no way of selecting the input source.
The kernel does now automatically select the input source according to presence detection - the headset mic becomes active when the headset is connected, and it reverts back to internal mic when it is disconnected.
However, Pulseaudio/GNOME UI continues to offer the user the possibility of selecting between internal & headset mic, and changing the selection has no effect, so the UI is broken :/
At this point we have the open question of "is this a bug or a feature?". i.e.:
1. When auto_mic is active, userspace has no way to control which of the input sources is active, so it is a bug that pulseaudio offers a UI that suggests that the user can select the input source
or:
2. This is a kernel bug. auto_mic should dynamically switch the mic based on presence detection, but userspace should still be able to select a different input source via cswitch mixer controls.
Or we're thoroughly misunderstanding something?
> These "Headset Mic" controls are only for playback direction and have nothing
> to do with the capture. That is, these are only for analog-loopback volumes,
> and don't influence on the capture stream.
So you are saying that if we adjust the Headset Mic volume control in alsamixer it should have no effect on the volume of the audio captured via the headset mic jack? In the non-auto-mic mode is the cswitch aspect of this mixer control also unrelated to capture?
First of all, Realtek codecs have *no* dedicated capture volume for each input route (except for the boost volumes). There is only one capture volume assigned to each ADC, and each pin may have mute controls, but that's all. Wrt auto-mic: if this flag is set, solely the kernel takes the control of the capture source selection. And this flag is set automatically when a jack-detectable external mic pin and a fixed internal mic pin are found. So, if this doesn't work as expected, it essentially means that something wrong in your quirk, not the core code. Check whether the mic jack detection really works as advertised in quirk. > Wrt auto-mic: if this flag is set, solely the kernel takes the control of the > capture source selection. And this flag is set automatically when a > jack-detectable external mic pin and a fixed internal mic pin are found. OK thanks. This was just uncertainty around expectations then. We were not sure if it was intended that userspace would be unable to change which mic is used when running in auto_mic mode. Since you say its solely the kernel in charge then the following conclusion from above is the valid one: > When auto_mic is active, userspace has no way to control which of the input > sources is active, so it is a bug that pulseaudio offers a UI that suggests > that the user can select the input source This does seem a bit suboptimal though. By choosing the active mic and not allowing userspace to choose, it feels like the kernel is baking in policy decisions over which mic to use. It's a reasonable enough policy to not raise any major concerns, but it seems like there should be a bit more flexibility involved, e.g. the ability for pulseaudio to opt out of those policy decisions and regain control of capture source selection. Do you think it would be worth some discussion/development along those lines? You can disable the auto-mic feature by passing the driver hint "auto_mic=0". See Documentation/sound/hd-audio/notes.rst. That's handy for experimentation, but that mechanism is not really available to pulseaudio, which doesn't even run as root. We filed an issue with pulseaudio to see what they think about this situation: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/610 |
Created attachment 280003 [details] The audio related logs - alsa-info We are confused by the pin auto detection feature when we try to enable the headset's microphone of an Acer AIO desktop. It is Realtek ALC269VC CODEC which supports the auto detection feature. If I unset bit 0 of the Misc field, then it is an auto mic. System changes the headset's mic as the input source and only gets sound from headset's mic when the headset is plugged, even I choose the internal mic as the input source. If I set bit 0 of the Misc field, then it is not an auto mic. System gets sound from headset's mic and internal mic correctly with proper setting when the headset is plugged. If the internal mic is chosen, system only gets sound from internal mic. If the headset's mic is chosen, system only gets sound from headset's mic. That seems weird for the auto detection feature: When the headset is plugged, I choose the internal mic as the input source, but system only gets sound from headset's mic.