Created attachment 296441 [details] Screenshot of audio mixer, microphone section, when workarounds are applied I have a laptop, HP dc0019ur. Yep, another HP laptop. It has trouble correctly detecting internal mic, external microphone and headphone microphone. Both jack insert events and audio mapping (channels and whatnot) are not right, and mute led does not work. Through trial and error I managed to make it working with: 1) creating file /etc/modprobe.d/omen-audio.conf with contents: snd_hda_intel option model=hp-line1-mic1 2) Few changes in hdajackretask utility. hdajackretask created file: /*******************/ [lukas@0sm0dex ~]$: cat /lib/firmware/hda-jack-retask.fw [codec] 0x10ec0295 0x103c84da 0 [pincfg] 0x12 0xb7a60130 0x13 0x40000000 0x14 0x411111f0 0x16 0x411111f0 0x17 0x90170110 0x18 0x411111f0 0x19 0x02a11030 0x1a 0x411111f0 0x1b 0x04a19030 0x1d 0x40600001 0x1e 0x411111f0 0x21 0x03211020 /*******************/ With this, mute led works, dedicated mic jack has clear stereo audio, headphones jack has clear mono audio from headphones mic, internal microphones work (there are two symmetrically placed mics on top of laptop lid). Not sure if internal mic should be stereo, or one of them should be for noise cancellation and if this issue is not a seperate one (it picks up fan noise quite well) Both external microphones are detected when plugged in (headphone ones are detected if 4-pin headphones are plugged in) in the picture I attached, "Front Microphone" is actually microphone from headphones, "Microphone" is dedicated mic port, and Internal is laptops internal. The word beginning with "(" in the drop-down menu translates into "disconnected". Extra info: when diagnostic files were generated (alsa-info) kernel: 5.10.1-xanmod1-MANJARO OS: Manjaro 20.2 (testing branch) alsa-info.sh diagnostic file link with workarounds applied: http://alsa-project.org/db/?f=1e56d10c301df770a04cf74fa36661a77d94c527 Just to be clear - sound output works fine, both from headsets and internal laptop speakers. Currently running Linux 5.11.15, though the fix is still needed. I'd be happy to assist in testing, as I'd like to see this fix applied upstream. Sincerely, Lukas.
To expand on hdajackretask: I am not sure what I have changed there, I am also not sure if all those changes are necessary or proper/correct. I tinkered with it a bunch of times until I had everything working fine.
Thanks for the report. Could you check whether the patch below works?
Created attachment 296601 [details] Test fix patch
(In reply to Takashi Iwai from comment #3) > Created attachment 296601 [details] > Test fix patch I'll try testing it later this day. Seems like Manjaro does not want to compile alsa from AUR without dependency breakage. I will try Ubuntu liveCD (it allows full alsa restart quite easily), or install arch/gentoo into usb stick. I don't know if there are simpler solutions, hope that this will suffice. Thanks for the patch, stay tuned (hehe).
Well, the patch is for kernel, not alsa-lib or such. Just to be sure.
Makes sense as this is a kernel bugzilla... Sorry, I mixed ALSA from kernel and ALSA as application/library. I've started compiling the kernel.
Sorry for the delay. I've compiled the kernel, disabled the workarounds, works just like with the workaround. Booted to another (non-patched) kernel to be sure, did not work. So, in conclusion - it works :)
Some issues popped up as I haven't tested it very well... I am not sure if those issues are related to Pipewire or bad headphones microphone (or my OS misconfiguration, for that matter). In any case, I'll do more testing to see that everything is working OK. Hold on to the patch for now.
Hrm, OK. The patch hasn't been merged yet, so ping me if it actually works or more changes are needed.
Created attachment 296631 [details] Test recording using internal mic with crackling sounds
Every component works fine, except internal mic. It *had* issues before the workaround (stock kernel and no hdajackretask'ing), but it was different (actually, worse). Now it presents low-volume though noticeable small crackling sound. I tried checking if AC adapter would cause this, and the issue still appeared. Could be that the internal mic is trash, or the circuitry is inadequate in suppressing electrical noise. To be honest, the situation is improved with this patch in all fronts, and only somewhat incomplete fix is internal mic, that still works better than without all the trickery. Current concerns are of nitpicky nature (though, I believe, valid). I will try poking around a bit, maybe also trying stock OEM drivers on top of Windows 10 PE.
I would also like to add, that current patch could, in my opinion go upstream as-is.
Could you give alsa-info.sh output and dmesg output? I'm not sure about the built-in mic problem. It could be that the system needs to use ASoC SOF driver instead for DMIC. Usually the system chooses the right one depending on the existence of DSP, etc, which can be seen in the kernel log.
Meanwhile I submitted the current patch. It'll be merged in 5.13-rc1 likely in the next week.
Created attachment 296635 [details] dmesg output dmesg output (with patched liquorix 5.11.18 kernel)
Created attachment 296637 [details] alsa-info.sh file (using patched kernel) alsa-info.sh script (version 0.5.0) generated file with patched Liquorix 5.11.18 kernel
Though alsa-info will most likely show this, but there are few unnecessary/unusable controls present in alsa-mixer. 1) S/PDIF and S/PDIF{1-4} can only be muted/unmuted (with volume level 0) though I am not sure if this is OK / not OK. 2) "Mic Mute-LED Mode" is unnecesary as the keyboard has only sound (speakers/headphones jack) mute led. 3) [Playback] has all items of [Capture], resulting in duplicates when watching [All] (controlling one of these will control BOTH. Also not sure if this for some legitimate reason.
Created attachment 296641 [details] Alsa-mixer [Capture] section when patch is applied
Created attachment 296643 [details] Alsa-mixer [All] section when patch is applied
Both can be safely ignored. The SPDIF here are rather about HDMI/DP digital bits, so they are valid controls. The mic-mute LED stuff is harmless (although it's useless). In 5.13 kernel, this control was moved to a sysfs entry, and is even less bothering.