Re: [PATCH v2] ALSA: hda/conexant: fix FEVM FA880 PRO internal mic mux

[周Ocean]

Hi Takashi,

Thank you for the suggestions. I have tested the stock driver as requested.

Here are the results:

1. Does the jack detection work for the rear jack? Yes, the jack
detection works properly for the rear jack.

2. Does the output from the rear work as-is? Yes, the output works
normally. I primarily use this jack for an external TRS speaker.

3. Changing the pin control of 0x1c: I plugged a TRRS headset (with a
microphone) into the rear jack. Both the audio output and the headset
microphone worked properly without any modifications. When I ran sudo
hda-verb /dev/snd/hwC1D0 0x1c SET_PIN_WIDGET_CONTROL 0x00, the
headphone output stopped as expected, and the microphone continued to
work normally.

Based on these tests, the rear jack is a fully functional TRRS combo
jack, and there is no hardware interference between the output (0x1c)
and input (0x1b) pins.

The loud buzzing noise I reported earlier occurs only when a 3-pole
TRS plug (like my external speaker or a standard headphone without a
mic) is connected to the rear jack. It appears the hardware lacks
proper impedance sensing to distinguish between TRS and TRRS plugs,
and blindly leaves the mic input pin (0x1b) active. Since the TRS plug
shorts the mic ring to ground, the active 0x1b pin captures ground
loop noise.

This behavior is consistent with what I observe on Windows on the same
machine: when a TRS speaker is plugged in, Windows shows a microphone
device that captures no sound, likely because the pin is shorted to
ground.

Given that this machine is a Mini-PC and the rear jack is mostly used
for TRS external speakers, would applying a pin quirk to disable 0x1b
(setting it to 0x40000000) be the most appropriate upstream fix?

Best regards,

Ocean

Takashi Iwai <tiwai@xxxxxxx> 于2026年6月8日周一 15:28写道：
>
> On Sun, 07 Jun 2026 19:40:13 +0200,
> 周Ocean wrote:
> >
> > Hi Takashi,
> >
> > A quick follow-up to my previous email! I have a correction to make.
> >
> > First, I must apologize for a bit of confusion regarding the "loud
> > electrical hum" I mentioned. I realized that during my earlier
> > troubleshooting, I had accidentally cranked the Internal Mic Boost to
> > a massive +48dB in alsamixer to see if I could force any signal to
> > appear. After lowering the boost to a normal level, the stock driver's
> > behavior is exactly as I originally described: mostly silent but only
> > captures faint acoustic tapping on the chassis, with no actual voice.
> >
> > More importantly, following your guidance, I managed to find the
> > perfect and elegant fix for this issue!
> >
> > Instead of using my previous brute-force hack (locking the ADC to
> > 0x1e), I wrote a proper HDA pin override quirk for this machine (PCI
> > Subsystem ID: 0x2014:8004). The quirk simply sets the pin default for
> > the phantom Rear Mic (Node 0x1b) to 0x40000000 ([N/A] None).
> >
> > Once Node 0x1b is disabled, ALSA's auto-parser magically handles the rest:
> >
> > Without a headset plugged in, the system automatically defaults the
> > capture to 0x1e (Internal Mic), completely eliminating the noise and
> > allowing normal voice capture.
> >
> > When I plug a headset into the front panel, the system dynamically
> > switches the input to 0x1a (Front Headset Mic), and it works
> > perfectly!
> >
> > As for the rear speaker not auto-muting, I discovered that Auto-Mute
> > Mode was simply set to Disabled in my ALSA mixer. After enabling it,
> > the rear speaker correctly auto-mutes when the headset is plugged in.
> >
> > Just as you pointed out in your earlier email, hard-wiring the
> > connection wasn't the right approach. It seems that correcting the pin
> > default to hide the phantom node (0x1b) allows the parser to wire the
> > expected routes naturally. Could you let me know if using
> > HDA_FIXUP_PINS for this is the correct implementation route? If this
> > approach aligns with the proper topology handling, I would be very
> > happy to prepare and submit a v2 patch.
>
> Yes, disabling the pin config with that fixup makes sense.
>
> There are a few more things you can test, though:
>
> - Does the jack detection work for the rear jack?
>   There are two pins assigned, NID 0x1b and 0x1c for input and output.
>
> - Does the output from the rear work as-is?
>
> - If the output works, try to change the pin control of the output of
>   the rear jack (NID 0x1c), e.g. via hda-verb.  As default it's 0x40,
>   and set to 0x00.  Does it change anything on the input from that
>   jack?
>
>
> Takashi