I’'m not OP, but I had the same problem, I used the first way and it fixed the issue, thank you so much!
OP has a different Product ID shown in alsa-info.sh data 0x1043, 0x1bc0
!!HDA-Intel Codec information
Codec: Realtek ALC295
Subsystem Id: 0x10431bc0
I cannot find a patch added to kernel for 0x1043, 0x1bc0 or 0x1043, 0x1011
has this patch been reported to bugzilla or pushed to kernel developers?
i did find a recent patch for Asus GA702 - 0x1043, 0x1e11
https://lkml.org/lkml/2020/8/3/720
that patch is reconfiguring pin 0x19, that appears to be the same pin/node that is incorrectly detected on OP’s system as a speaker instead of a microphone
Node 0x19
Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
Control: name=“Headset Mic Boost Volume”, index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00003724: IN Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=02, enabled=1
Power states: D0 D1 D2 D3 EPSS
Power: setting=D0, actual=D0
can you please share alsa-info.sh data for patched system
it might be possible to work out a solution using hdaverb or hdajackretask
My opinion is that the code that causes regression should be removed from the source code, instead of coming up with countless patches for each model. I showed you in my patch “realtek-5.8.3.patch” which changes cause regression. I have never submitted bug reports and do not know how to properly convey this to the developers.
Commit #1, commit #2, most likely the first commit is causing the problem.
Hi Takashi,
ASUS platform couldn’t need to use Headset Mode model.
Attach patch will change it.BR,
Kailang
And everything broke, just fine.
Just to know, is there a place (kernel bugs? alsa bugs? … bugs?) where can I report this issue too?
Unfortunately I need a working microphone and, sadly, I do not know how to compile the patch you kindly provided; for these reason I asked if there was a “place” where reporting bugs like this thus they could be solved “upstream”.
Edit:
Bug reported here https://bugzilla.kernel.org/show_bug.cgi?id=209045
1 Like
your alsa-info.sh data includes DMESG data to confirm that pin 0x19 relates to the headset microphone location
[ 6.261983] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19
I did some difference comparisons on the ALSA data for the 3 similar laptops identified so far
GL703GE @rovovav982 [1043:1bc0]
GL703GM @ZeroAnarchy [1043:1011]
GL503VD @pidz-b [1043:1bb0]
I expected to see a difference in the configuration for pin 0x19, but configurations for all 3 are identical
/sys/class/sound/hwC0D0/init_pin_configs:
0x12 0x90a60130
0x13 0x40000000
0x14 0x411111f0
0x16 0x411111f0
0x17 0x90170110
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x40679a2d
0x1e 0x411111f0
0x21 0x03211020
main difference appears to be that your system has kernel v5.8.3 and the other systems have v5.8.1
I had the same problem and used method one. Thanks so much for posting your solution. Have a great day!
Method one works for me, for headphone AND microphone. Thank you !
Have a great days !
I tried the first solution, and my headset audio finally worked again, but as expected, the mic didn’t work anymore. After doing some research I tried pasting “options snd-hda-intel model=dell-headset-multi” to “/etc/modprobe.d/alsa.conf” instead, and this completely fixed the problem (I have a ASUS GL703VM). When booting with the headset plugged in, you often have to unplug and plug in again for it to work. (Actually, every time you plug in a device to the audio jack, it asks what kind of device it is).
Thank you for helping me find the solution!
1 Like
I had no sound for months. Thanks for this thread. I suggest someone pin it, please.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.