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

[周Ocean]

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