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

[周Ocean]

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.

Best regards,
Ocean

周Ocean <zhouoceanhy@xxxxxxxxx> 于2026年6月8日周一 00:48写道：
>
> Hi Takashi,
>
> Thank you for pointing that out.
>
> The physical reality of my machine is that it does not have a
> dedicated "Rear Mic Jack" at all. The rear panel only has one single
> audio jack, which I am currently using to plug in my external speaker
> (standard TRS, so no built-in mic).
>
> You are exactly right about the route. Because the system falsely
> reports a "Rear Mic" as plugged in and routes ADC 0x14 to pin 0x1b
> (which is physically missing/floating on my motherboard), it generates
> the static noise.
>
> In the patch I submitted earlier, I made a brute-force modification to
> force the ADC to connect to the internal host microphone (Pin 0x1e,
> conn index 3): snd_hda_codec_write(codec, 0x14, 0,
> AC_VERB_SET_CONNECT_SEL, 0x03); This successfully bypassed the
> floating 0x1b pin, immediately silenced the noise, and got my built-in
> host mic working.
>
> However, this hardcoded patch completely breaks the front panel audio routing:
>
> When I plug a headset into the front panel, the OS does detect the
> plug event (I get a volume change notification), but the rear speaker
> does not auto-mute. Both the front headset and the rear speaker play
> sound simultaneously.
>
> Because my patch locks the ADC to the internal mic, the front panel
> microphone cannot be dynamically switched to and does not work at all.
>
> I also noticed another clue regarding the behavior of this noise:
>
> Without my patch (stock driver): The noise is a very loud, constant
> buzzing/humming sound. It completely fails to capture any voice, and
> even tapping the Mini-PC chassis leaves absolutely no signal in the
> recording.
>
> In a previous older state (before forcing this widget connection): The
> noise behaved differently—it was mostly silent, but it would capture
> the acoustic vibration of tapping the Mini-PC chassis, though it still
> wouldn't record actual voice.
>
> This shift to a pure, loud electrical hum further confirms that
> without the patch, the input is routed to a completely
> floating/unterminated pin (0x1b), which picks up heavy environmental
> EMI.
>
> To show you the physical layout, I have uploaded a photo of my
> computer's rear panel here: https://sm.ms/kyPL
>
> Given this messy pin configuration from the manufacturer, what would
> be the proper way to handle this via pin configs or a quirk so that
> the internal mic works by default, while retaining dynamic switching
> and auto-muting for the front panel? Please let me know if you need
> any further diagnostics or logs.
>
> Best regards,
> Ocean
>
> Takashi Iwai <tiwai@xxxxxxx> 于2026年6月7日周日 20:16写道：
> >
> > On Sat, 06 Jun 2026 16:19:26 +0200,
> > 周Ocean wrote:
> > >
> > > Hi Takashi,
> > >
> > > To be honest, I'm not an expert on the low-level hardware design of
> > > this codec, but I can confirm that the internal microphone only works
> > > normally when we apply this patch.
> > >
> > > I realized why the previous two dumps were identical: the user-space
> > > audio server (PipeWire) automatically restored the routing and
> > > switched NID 0x14 to NID 0x1e (index 3) at runtime, masking the actual
> > > boot defaults.
> > >
> > > This time, I stopped PipeWire entirely, reloaded the stock driver, and
> > > captured the true hardware defaults. Please find the new logs
> > > attached:
> > >
> > > 1. alsa-info-raw-defaults.txt.gz (Stock driver, pure hardware defaults):
> > > Here, NID 0x14 actually defaults to NID 0x1b (index 1, Rear Mic) on boot:
> > >    Connection: 4
> > >       0x1a 0x1b* 0x1d 0x1e
> > >
> > > 2. alsa-info-with-patch.txt.gz (Patched driver):
> > > Here, the quirk forces it to NID 0x1e (index 3, Internal Mic) at initialization:
> > >    Connection: 4
> > >       0x1a 0x1b 0x1d 0x1e*
> > >
> > > Without the patch, testing the microphone in the stock driver yields a
> > > loud buzzing/humming noise (typical of a floating/unconnected input
> > > pin on NID 0x1b) with only a very faint sound when tapping the chassis
> > > (due to signal crosstalk/leakage from NID 0x1e to NID 0x1b). Even if
> > > PipeWire switches the connection to 0x1e at runtime later, it fails to
> > > record normal sound.
> > >
> > > Applying the quirk at ACT_INIT ensures NID 0x14 is correctly mapped to
> > > the physical internal mic pin (0x1e) from boot, resolving the floating
> > > pin noise and restoring mic capture to a normal level.
> >
> > Looking at your alsa-info.sh outputs, it shows that the rear mic jack
> > is plugged:
> >
> >         control.17 {
> >                 iface CARD
> >                 name 'Rear Mic Jack'
> >                 value true
> >                 comment {
> >                         access read
> >                         type BOOLEAN
> >                         count 1
> >                 }
> >         }
> >
> > so the driver makes ADC 0x14 connected to 0x1b, which is the pin
> > for the rear mic.
> >
> > If you get a noise from it, it means that something wrong with that
> > route.
> >
> >
> > Takashi