Created attachment 306722 [details] $(dmesg | grep -iE 'snd|hda|realtek|alc|cirrus') and $(cat /proc/asound/card2/codec#0) Laptop Model: Asus ROG G14 GA402XY Codec: Realtek ALC285 + Cirrus logic cs35l41 OS: Debian Testing Kernel: 6.9.x, 6.10 represents the issue, 6.8.x no DE: Gnome 46, wayland Here's the issue. When using the 6.9 or the 6.10 kernel system doesn't see an external mic from the headset (3.5 jack). Instead, there's only an internal mic available. When using the 6.8 kernel or less it's okay, I can use mic from the headset. So currently I'm on 6.8.12. What I've tried: - Play with snd_hda_intel model parameters from there: https://www.kernel.org/doc/html/latest/sound/hd-audio/models.html?highlight=headset+mic ex: options snd_hda_intel model=dell-headset-mic - Retask jack with hdajackretask - Install a fresh system on another ssd (latest PopOS) - after kernel update to 6.9.x (from the repository) it's the same issue.
System Information: Laptop Model: Asus ROG G14 GA402XY Codec: Realtek ALC285 + Cirrus Logic CS35L41 Operating System: Arch Linux Kernel: Issue starts from version 6.9; 6.8.x works (tested up to 6.8.9) Desktop Environment: KDE 6.2.3 + Wayland I performed a bisection to identify the cause of the headset microphone issue. The first commit introducing the problem is the following: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0e02ca29a5634dfb90fe1bad9467ee0965a1e170 Starting from this commit, the headset microphone is no longer recognized. After investigating further, it seems the issue is related to the sort.r function in lib/sort.c. To verify, I checked out the latest stable kernel and replaced the sort.r function with the version from the last known "good" kernel (commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/lib/sort.c?id=db946a42226052a13fbce8757ff77b3107dd2030#n210). With this change, the headset microphone works correctly, even on the latest kernel.
Hi all, this appears to still be an issue for many similar asus laptop models. It is a regression caused by the commit above which was bisected. sort() wraps sort_r(), and is used by pci/hda sound by hda_auto_parser and hda_generic. One would assume that the sort_r() broke in some way the behaviour or sort() such that maybe an incorrect item is returned?
Update on troubleshooting I experimented with swapping the current sort_r() implementation with the version from the last known good commit. - On Linux stable 6.12.0-rc7, swapping the sort_r() implementation makes the microphone work reliably, as I mentioned back in November. - On the latest stable kernel (6.13-rc7), however, swapping the sort_r() implementation makes the microphone behave inconsistently. Most of the time, it isn’t detected when plugged in. Once it is recognized, though, it will consistently work after unplugging and re-plugging. Interestingly, it seems to start working only after a series of PipeWire warnings have appeared (but not immediately after), such as: graph xrun not-triggered. - On stable kernel, with the new sort_r() implementation, the headset microphone never works at all, starting from 6.9 In conclusion: sort_r() does play a contributing role, and reverting it on kernels at least up to 6.12.0-rc7 was a reliable workaround, but it isn't anymore. I'm happy to share additional logs, run more tests, or help with further troubleshooting if needed.
Created attachment 307488 [details] revert sort_r changes
Created attachment 307489 [details] revert some realtek_patch changes
Starting with 6.12.2 some commit broke mic again It happened somewhere here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?id=e3ea2757c312e51bbf62ebc434a6f7df1e3a201f (or in +-1 commit). I just reverting changes with patches (in addition to fixing sort_r) and mic works in the latest kernels (like now i'm on the 6.12.9).
Hi, I'm the author of the patch optimizing sort(). I suspect the issue is caused by a broken compare function in sound/pci/hda/hda_auto_parser.c. Could you help test the code I shared in the email [1]? Thanks! [1]: https://lore.kernel.org/lkml/Z4euvhAXAiZXCObx@visitorckw-System-Product-Name/
Hello! I just tried this patch for sound/pci/hda/hda_auto_parser.c with the latest kernel (without changing sort_r), but no luck.
(In reply to Austrum from comment #8) > Hello! > > I just tried this patch for sound/pci/hda/hda_auto_parser.c with the latest > kernel (without changing sort_r), but no luck. That's sad :( Just to make sure, was the test done with the Realtek patches reverted as mentioned above?
Yep. I got the same kernel I'm using rn just with this patch instead of reverting sort_r function (realtek reverting patch was applied)
From the provided log, it appears that after sorting the input types in hda_auto_parser, the order of Mic=0x19 and Mic=0x1b has been swapped. Could this be the cause of the issue? To investigate why their order was swapped, printing cfg->inputs[i].type, cfg->inputs[i].is_headset_mic, cfg->inputs[i].is_headphone_mic, and cfg->inputs[i].has_boost_on_pin after sorting might help clarify further.
Created attachment 307532 [details] Patch for printing cfg->inputs[i] and including patch_realtek.c revert
> From the provided log, it appears that after sorting the input types in > hda_auto_parser, the order of Mic=0x19 and Mic=0x1b has been swapped. Could > this be the cause of the issue? To investigate why their order was swapped, > printing cfg->inputs[i].type, cfg->inputs[i].is_headset_mic, > cfg->inputs[i].is_headphone_mic, and cfg->inputs[i].has_boost_on_pin after > sorting might help clarify further. I tried this out: - I applied the patch for /sound/pci/hda/hda_auto_parser.c - I applied the patch for /sound/pci/hda/patch_realtek.c - I did not apply the patch for /lib/sort.c - I added a print for each input after sort is called on inputs As Austrum reported, the headset mic still doesn't work. And here's the print output: Input 0: type=0, headset_mic=0, headphone_mic=0, boost_on_pin=1 Input 1: type=0, headset_mic=0, headphone_mic=0, boost_on_pin=1 Input 2: type=0, headset_mic=0, headphone_mic=0, boost_on_pin=1 Input 3: type=0, headset_mic=0, headphone_mic=0, boost_on_pin=1 I'm not sure how much helpful it is, as I get the exact same print even if I apply the patch for sort.c, with which I can confirm the headset mic works. You can find the exact patch as an attachment. Hopefully I understood correctly and added the print at the spot you wanted it at. If you can provide additional patches for debugging, I'll be happy to provide logs.
Since the four elements' value here are the same and sort() is not a stable sort, it's valid for sort() to arbitrarily swap their order. So, it doesn't seem like the issue is here. :( I previously suspected this compare function because commit 6a6ca7881b1a ("ALSA: hda - let hs_mic be picked ahead of hp_mic") modified it to fix a headset audio output issue and mentioned its connection to patch_realtek. This seemed highly related to this issue. Under the sound/ directory, there are only three calls to sort(). Aside from this one, the other two sort integers, which seem less likely to cause issues. But if all three sort() calls are correct, I currently have no idea what the cause of the problem could be. :(
Could you give the alsa-info.sh outputs from both working and non-working cases? Run the script with --no-upload option and attach the outputs.
Created attachment 307540 [details] alsa-info-sort_r
(In reply to Takashi Iwai from comment #15) > Could you give the alsa-info.sh outputs from both working and non-working > cases? > Run the script with --no-upload option and attach the outputs. Done. Attachement in "alsa-info-sort_r" contains: - alsa-info_6.8.12.txt - from old 6.8.12 kernel without any patches. Latest raw working kernel. - alsa-info_6.12.11_broken.txt - latest 6.12 kernel without reverting sort_r patch. Mic doesn't work. It also have applied the reverting realtek_patch patch. - alsa-info_6.12.11_with_revert.txt - latest 6.12 kernel with reverting sort_r patch. Mic does work. It also have applied the reverting realtek_patch patch.
Thanks. Could you try the patch below?
Created attachment 307541 [details] Test workaround patch
Created attachment 307542 [details] fix-compare-input-type.patch If the issue is making sort() behave like a stable sort, comparing the pointers of equal elements is not correct, as heapsort might swap two elements without comparing them. Could you try the following patch instead?
(In reply to Kuan-Wei Chiu from comment #20) > Created attachment 307542 [details] > fix-compare-input-type.patch > > If the issue is making sort() behave like a stable sort, comparing the > pointers of equal elements is not correct, as heapsort might swap two > elements without comparing them. Could you try the following patch instead? Thanks, it's a good point. Please try the comment 20 instead of mine.
(In reply to Kuan-Wei Chiu from comment #20) > Created attachment 307542 [details] > fix-compare-input-type.patch > > If the issue is making sort() behave like a stable sort, comparing the > pointers of equal elements is not correct, as heapsort might swap two > elements without comparing them. Could you try the following patch instead? It seems to be working! I applied the fix-compare-input-type and reverting realtek_patch patches and mic is working on a fresh kernel.
Good to hear! Kuan-Wei, care to submit the patch, so that I can merge for the upstream?
Glad to hear that. Sure, I'll write an appropriate changelog and send a formal patch. Austrum, May I include your Reported-by and Tested-by tags in the patch? i.e. Reported-by: Austrum <austrum.lab@gmail.com> Tested-by: Austrum <austrum.lab@gmail.com>
(In reply to Kuan-Wei Chiu from comment #24) > Austrum, > May I include your Reported-by and Tested-by tags in the patch? Sure thing. Thank you! And all other involved people. Shell we discuss the other problem (with realtek_patch) here or I need to open another bug? (I mean what's the correct way here)
Let's close.