hdajackretask doesn't work anymore?

seth · 2026-09-09 15:44:46

Is it possible to fry a mic with HDAJackRetask?

You'll have to ask that upstream but I suspect that would very much depend on the specific hardware and it seems implausible.
Have you retried the originally working condition?

0x18, 0x1a, and 0x1d to "Internal microphone" … all of the other ones … I had these set to "not connected" to identify the pin

thesupertechie · 2026-09-09 18:46:00

Well, fortunately, I didn't fry my mic. Here's something interesting I found. When I boot the kernel without snd_intel_dspcfg.dsp_driver=1 and any microphone overrides, my mic works (even without an override in HDAJackRetask). However, I noticed that HDAJackRetask doesn't show my config. When I boot with that kernel parameter, my mic is not detected, but HDAJackRetask shows my config. Does this mean that the overrides aren't loaded when I use snd_intel_dspcfg.dsp_driver=1? I assume that HDAJackRetask is just glitching in this case? Any way to check if it is loading the patch firmware without the kernel parameter?

Seth wrote:

Have you retried the originally working condition?

Yes, sorry for being unclear. I tried that before posting my last message and no dice. The closest I got was garbled mic input.

seth · 2026-09-09 20:06:28

https://bbs.archlinux.org/viewtopic.php … 9#p2304189

V1del wrote:

you're running on Sof here, afaik hda jack retask never really worked with that

So basically your MIC seems to rely on SOF but that breaks your hdajackretask efforts…
You might get the mic to work by explicitly selecting a different model, https://wiki.archlinux.org/title/Advanc … odetection

thesupertechie · 2026-09-09 20:09:02

Adding "snd_hda_intel.model=model" to my GRUB parameters will work, correct?

seth · 2026-09-09 20:12:05

It will affect that parameter - whether it will activate your mic (w/ any model) is to be seen

V1del · 2026-09-09 21:36:00

Afaik (I don't have any hardware running into this and so this is just some educated guesses based on what I've seen) if you're on hardware that requires to "disable" SoF to get to the HDA path that implicitly disables the mic without chance of a fix (i.e. the dmic that gets disabled with the old method of switching the DSP to HDA via snd-hda-intel.dmic_detect=0)

So you either need to get this working with the sof path that disables hdajackretask or live with no mic. You might be able to replicate your hda pin layouts by playing with the appropriate configs in the ucm config files under /usr/share/alsa/ucm2 ... when not using the dsp driver parameter (hence hdajackretask not working) what mixer controls does amixer expose for the card?

Last edited by V1del (2026-09-09 21:49:35)

thesupertechie · 2026-09-09 23:22:04

Seth wrote:

It will affect that parameter - whether it will activate your mic (w/ any model) is to be seen

Unfortunately, that did not work

V1del wrote:

You might be able to replicate your hda pin layouts by playing with the appropriate configs in the ucm config files under /usr/share/alsa/ucm2

Could you please explain how to achieve this or link me to a resource?

V1del wrote:

what mixer controls does amixer expose for the card?

With my applied HDAJackRetask config, I see:
Master
Headphone
Speaker (no slider)
Bass Speaker
PCM
Mic Boost
S/PDIF (no slider)
S/PDIF 1 (no slider)
S/PDIF 2 (no slider)
S/PDIF 3 (no slider)
Capture
Auto-Mute Mode (Disabled)
Digital

EDIT: Is there a way to check if HDAJackRetask's adjustments are being applied on boot? Also, this may be me misremembering, but I feel like HDAJackRetask used to work without any specialised parameters. In addition, here are the mixers with the kernel parameter disabled (i.e. HDAJackRetask shouldn't be running):
Master
Headphone
Speaker
Mic Boost
S/PDIF (no slider)
S/PDIF 1 (no slider)
S/PDIF 2 (no slider)
Capture
Auto-Mute Mode (disabled)
PGA1.0 1
PGA30.0
PGA31.0
PGA7.0 7
PGA8.0 8
PGA9.0 9

Last edited by thesupertechie (2026-09-09 23:47:09)

seth · 2026-09-10 05:30:07

Unfortunately, that did not work

I blindly trust V1del on this but just tbc, "model" is a placeholder - there're countless options

Also, this may be me misremembering, but I feel like HDAJackRetask used to work without any specialised parameters.

Do you remember (mis or not) the system configuration where this worked?

From what we've learned that would have had to predate SOF (introduced summer 2021?) - or happened on hardware that didn't use it.

thesupertechie · 2026-09-10 21:00:26

Do you remember (mis or not) the system configuration where this worked?

I feel like it worked in some capacity in Fedora? But this laptop was released in 2023, I got it in 2024, and first installed Fedora in 2024 then Arch in late 2024. But this was after SOF (after 2021). I have did not use Linux before 2021. So it may be a mismemory, but I remember even then on Fedora I needed to do some fighting with HDAJackRetask, even on the previous computer I used a different distro on 2024.

V1del · 2026-09-11 14:39:32

seth wrote:

I blindly trust V1del on this ...

I'm honored but I really don't have that much exp here either sadly

@thesupertechie For the question whether HDAJackRetask was applied, dmesg will show a line as mentioned in post #4. But do you potentially mix the experience from "previous computer" with this one? Because a pure HDA card will also have the mic on the HDA path, and in this case everything will work and also be able to be manipulated with HDAJackRetask. Which is evidently not the case here.

I sadly also don't really have a good pointer on what to explicitly check in the ucm files, some general pointer is potentially check

#Replace correct hw: device nr if necessary
alsaucm -c hw:0 dump text

and look at the pointers in https://thesofproject.github.io/latest/ … -platforms and https://github.com/alsa-project/alsa-uc … 2/DEBUG.md -- and maybe even opening up a bug report with the relevant discrepancy to the sof project on github, maybe someone there has some better pointers to fix this properly.

Last edited by V1del (2026-09-11 14:46:44)

thesupertechie · 2026-09-12 17:56:00

V1del wrote:

alsaucm -c hw:0 dump text

Tried that, and I get this:

ALSA lib parser.c:306:(error_node) [error.ucm] UCM is not supported for this HDA model (HDA Intel PCH at 0x622d1d0000 irq 219)
ALSA lib main.c:1805:(snd_use_case_mgr_open) [error.ucm] failed to import hw:0 use case configuration -6
alsaucm: error failed to open sound card hw:0: No such device or address

I tried an index of 1, just in case, and got this:

ALSA lib confmisc.c:165:(snd_config_get_card) [error.core] Cannot get card index for 1
ALSA lib parser.c:3622:(uc_mgr_import_master_config) [error.ucm] card 'hw:1' is not valid
ALSA lib main.c:1805:(snd_use_case_mgr_open) [error.ucm] failed to import hw:1 use case configuration -2
alsaucm: error failed to open sound card hw:1: No such file or directory

Perhaps I should just open an issue with SOF?

EDIT: I've opened an issue here: https://github.com/thesofproject/sof/issues/11196

EDIT 2: Just clarifying, I'm assuming there's not much more I can do in this case besides juggling with the kernel parameters based on whether I want a mic or not?

Last edited by thesupertechie (2026-09-12 18:46:07)

Arch Linux

#26 2026-09-09 15:44:46

Re: hdajackretask doesn't work anymore?

#27 2026-09-09 18:46:00

Re: hdajackretask doesn't work anymore?

#28 2026-09-09 20:06:28

Re: hdajackretask doesn't work anymore?

#29 2026-09-09 20:09:02

Re: hdajackretask doesn't work anymore?

#30 2026-09-09 20:12:05

Re: hdajackretask doesn't work anymore?

#31 2026-09-09 21:36:00

Re: hdajackretask doesn't work anymore?

#32 2026-09-09 23:22:04

Re: hdajackretask doesn't work anymore?

#33 2026-09-10 05:30:07

Re: hdajackretask doesn't work anymore?

#34 2026-09-10 21:00:26

Re: hdajackretask doesn't work anymore?

#35 2026-09-11 14:39:32

Re: hdajackretask doesn't work anymore?

#36 2026-09-12 17:56:00

Re: hdajackretask doesn't work anymore?

Board footer