Re: [PATCH v2] ALSA: hda/conexant: fix FEVM FA880 PRO internal mic mux
Takashi Iwai <[email protected]> Wed, 10 Jun 2026 19:53:07 +0200
| Newsgroups | org.alsa-project.alsa-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 10 Jun 2026 17:19:01 +0200, Ocean wrote: > > 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? Have you tried ctx_fixup_headset_mic, BTW? I'm not sure whether this is applicable to your model, but worth for a try. If this doesn't work, then disabling the mic would be the simplest solution. thanks, Takashi