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

[Takashi Iwai <tiwai@suse.de>]

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