Bug 212733

Summary:	HP OMEN Laptop dc0019-ur: needs alsa quirk for proper microphone use, mute led
Product:	Drivers	Reporter:	Lukas Veitas (lveitas956)
Component:	Sound(ALSA)	Assignee:	Jaroslav Kysela (perex)
Status:	REOPENED ---
Severity:	normal	CC:	tiwai
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	5.11.15	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Screenshot of audio mixer, microphone section, when workarounds are applied Test fix patch Test recording using internal mic with crackling sounds dmesg output alsa-info.sh file (using patched kernel) Alsa-mixer [Capture] section when patch is applied Alsa-mixer [All] section when patch is applied

Description Lukas Veitas 2021-04-20 10:05:53 UTC

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.

Comment 1 Lukas Veitas 2021-04-20 10:08:33 UTC

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.

Comment 2 Takashi Iwai 2021-05-03 12:56:56 UTC

Thanks for the report.  Could you check whether the patch below works?

Comment 3 Takashi Iwai 2021-05-03 12:57:33 UTC

Created attachment 296601 [details]
Test fix patch

Comment 4 Lukas Veitas 2021-05-03 13:22:53 UTC

(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).

Comment 5 Takashi Iwai 2021-05-03 15:13:19 UTC

Well, the patch is for kernel, not alsa-lib or such.  Just to be sure.

Comment 6 Lukas Veitas 2021-05-03 16:51:22 UTC

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.

Comment 7 Lukas Veitas 2021-05-04 05:47:25 UTC

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 :)

Comment 8 Lukas Veitas 2021-05-04 09:18:04 UTC

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.

Comment 9 Takashi Iwai 2021-05-04 09:21:45 UTC

Hrm, OK.  The patch hasn't been merged yet, so ping me if it actually works or more changes are needed.

Comment 10 Lukas Veitas 2021-05-04 10:11:34 UTC

Created attachment 296631 [details]
Test recording using internal mic with crackling sounds

Comment 11 Lukas Veitas 2021-05-04 10:17:34 UTC

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.

Comment 12 Lukas Veitas 2021-05-04 10:19:17 UTC

I would also like to add, that current patch could, in my opinion go upstream as-is.

Comment 13 Takashi Iwai 2021-05-04 12:16:41 UTC

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.

Comment 14 Takashi Iwai 2021-05-04 12:19:58 UTC

Meanwhile I submitted the current patch.  It'll be merged in 5.13-rc1 likely in the next week.

Comment 15 Lukas Veitas 2021-05-04 13:39:27 UTC

Created attachment 296635 [details]
dmesg output

dmesg output (with patched liquorix 5.11.18 kernel)

Comment 16 Lukas Veitas 2021-05-04 13:43:27 UTC

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

Comment 17 Lukas Veitas 2021-05-04 16:51:07 UTC

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.

Comment 18 Lukas Veitas 2021-05-04 16:53:10 UTC

Created attachment 296641 [details]
Alsa-mixer [Capture] section when patch is applied

Comment 19 Lukas Veitas 2021-05-04 16:53:56 UTC

Created attachment 296643 [details]
Alsa-mixer [All] section when patch is applied

Comment 20 Takashi Iwai 2021-05-06 08:44:49 UTC

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.