[BUG] ASUS Zenbook S 14: No sound from DMIC #5325
Comments
|
Same here.. Using Linux Kernel 13.0 RC5 on Fedora and still the microphone is not functioning. Inxi output for Audio: |
|
Can you list what controls you have with But I doubt the SOF processing would cause what you see. Another idea is that has UCM correctly enabled the SDW codec DMIC. You can check with amixer cget if these csets in EnableSequence are done: |
kv2019i
added
SDW
I don't have these controls on my system. List of controls is available in alsa-info.txt in the top comment.
Confirmed that the EnableSequence is all done. |
|
That might be UCM issue. @dantmnf Can you try the latest UCM from https://github.com/alsa-project/alsa-ucm-conf? @charleskeepax @stuhenderson Could you take a look? |
|
Hi @bardliao, I have the same system and am experiencing the same issue. I tried the latest from that repo (installed via instructions in the README, including state purge), but no change -- still just a click at the beginning, then silence. Is there something else I can try, or additional debug info I can gather? Thanks! |
|
@pcgrosen Can you upgrade cs42l43.bin ? I thought it is a muted issue but it should not be. Because you could record a pop noise at the beginning. Now I guess you may need an upgraded cs42l43 firmware. |
I think we are already on the latest version since it has been in linux-firmware for (exactly) one year. |
|
Does anyone know exactly which DMIC is used by this device? It seems PCH DMIC is detected in the NHLT table, but I am not sure if it matches the real HW design or not. |
|
It do have 2-channel microphone and can be verified in Windows by moving a speaker around two microphones while recording: |
|
This laptop has host DMICs but is missing a quirk for such, we are looking at putting together a patch. |
@charleskeepax We may need to do some change other than adding a quirk. /*
* DMICs use up to 4 pins and are typically pin-muxed with SoundWire
* link 2 and 3, or link 1 and 2, thus we only try to enable dmics
* if all conditions are true:
* a) 2 or fewer links are used by SoundWire
* b) the NHLT table reports the presence of microphones
*/
if (hweight_long(mach->link_mask) <= 2)
dmic_fixup = true;
else
mach->mach_params.dmic_num = 0;https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/intel/hda.c#L1332 |
|
@dantmnf can you try the top two patches from here: https://github.com/CirrusLogic/sof-linux/commits/topic/asus-UX5406SA/ |
@rfvirgil I think manually applying the quirk via module parameter is equivalent to the two patches? I tried |
|
@dantmnf Ah, that will be the thing @bardliao was referring to. It should be loading sof-lnl-cs42l43-l0-cs35l56-l23-2ch.tplg, but the logic here: makes it decide that it doesn't have host mics, so it loads the wrong topology. |
|
@dantmnf @pcgrosen Can you try #5287 ? |
|
@bardliao Just before your comment, I've made some success: Found another quirk that would "fix" https://github.com/gregkh/linux/blob/v6.12.8/sound/soc/intel/boards/sof_sdw.c#L1065-L1071 Built diff --git a/tools/topology/topology2/production/tplg-targets-ace2.cmake b/tools/topology/topology2/production/tplg-targets-ace2.cmake
index 96237b413..74e4fc8ea 100644
--- a/tools/topology/topology2/production/tplg-targets-ace2.cmake
+++ b/tools/topology/topology2/production/tplg-targets-ace2.cmake
@@ -74,4 +74,12 @@ EFX_DMIC0_TDFB_PARAMS=line2_generic_pm10deg,EFX_DMIC0_DRC_PARAMS=dmic_default"
"cavs-sdw\;sof-lnl-cs42l43-l0-cs35l56-l23\;PLATFORM=lnl,NUM_SDW_AMP_LINKS=2,SDW_DMIC=1,\
SDW_AMP_FEEDBACK=false,SDW_SPK_STREAM=Playback-SmartAmp,SDW_DMIC_STREAM=Capture-SmartMic,\
SDW_JACK_OUT_STREAM=Playback-SimpleJack,SDW_JACK_IN_STREAM=Capture-SimpleJack"
+
+"cavs-sdw\;sof-lnl-cs42l43-l0-cs35l56-l23-2ch\;PLATFORM=lnl,\
+NUM_DMICS=2,PDM1_MIC_A_ENABLE=0,PDM1_MIC_B_ENABLE=0,\
+PREPROCESS_PLUGINS=nhlt,NHLT_BIN=sof-lnl-cs42l43-l0-cs35l56-l23-2ch.bin,\
+NUM_SDW_AMP_LINKS=2,SDW_AMP_FEEDBACK=false,SDW_SPK_STREAM=Playback-SmartAmp,\
+SDW_JACK_OUT_STREAM=Playback-SimpleJack,SDW_JACK_IN_STREAM=Capture-SimpleJack,\
+HDMI1_ID=6,HDMI2_ID=7,HDMI3_ID=8,DMIC0_ENHANCED_CAPTURE=true,\
+EFX_DMIC0_TDFB_PARAMS=line2_generic_pm10deg,EFX_DMIC0_DRC_PARAMS=dmic_default"
)And finally with quirks and topology override After reboot, The microphone mute LED on keyboard is on. No UCM configuration available. After However, replacing the topology file with yours doesn't work (with unpatched kernel and |
|
@bardliao I applied that patch onto my otherwise-clean 6.12.6 kernel, but I'm getting the same topology load error that @dantmnf just posted. Is there something else in the sof kernel fork (that isn't upstreamed) that I need? If so, I can try a clean build from that repo, but that will probably have to be tomorrow. |
|
@dantmnf @pcgrosen Can you try sof-lnl-cs42l43-l0-cs35l56-l23-2ch.zip? I updated the link IDs. @singalsu Any idea about the channel-swapped issue? |
|
@bardliao This file works but still have two channels swapped |
|
@dantmnf @bardliao Do you mean that PCH DMIC channels are swapped? If with PCH DMIC and not with a microphone at SDW codec, that might be a circuit schematic issue in the PC. There's a number of ways to swap it. Easiest would be likely with custom beamformer blob set up by UCMv2 SOF customization based on DMI ID (in SOF v2.11, but patches for UCM not yet merged). The NHLT DMIC blob could also swap it at HW level but it would need BIOS NHLT update to set up channels swap or load with topology a custom NHLT. |
|
Just noticed that recording on Windows with exclusive mode is also channel-swapped. Looks like the channels are swapped back by a software audio processing component. |
|
@singalsu Yes, the laptop uses PCH DMIC and not a microphone at SDW codec. |
Then maybe it would be best to follow Windows and prepare a beamformer (TDFB) blob that swaps the channels (please create an enhancement type issue for SOF for a channels swap solution). An example of DMI ID Based processing customize is in: We have also talked about developing a SOF example template component for developers that would swap channels as a minimal processing example. It could be used with a custom topology. |
This comment was marked as resolved.
This comment was marked as resolved.
The NHLT table also supposes that channel 0 is on right (well, assuming positive horizontal-offset means right) root@archlinux ~ # nhlt-dmic-info
{
"mics-data-version":1,
"mics-data-source":"acpi-nhlt",
"mics":[
{
"channel":0,
"type":"subcardoid",
"location":"laptop-front-panel",
"horizontal-offset":45,
"freq-low-band":100,
"freq-high-band":20000,
"vertical-angle-begin":-60,
"vertical-angle-end":60,
"horizontal-angle-begin":-50,
"horizontal-angle-end":50
},
{
"channel":1,
"type":"subcardoid",
"location":"laptop-front-panel",
"horizontal-offset":-45,
"freq-low-band":100,
"freq-high-band":20000,
"vertical-angle-begin":-60,
"vertical-angle-end":60,
"horizontal-angle-begin":-50,
"horizontal-angle-end":50
}
]
}Seems it is not designed to simply take channel 0 as left… |
|
@bardliao Are you going to submit a patch to add the new tplg to SOF? |
|
Did anyone test that https://github.com/CirrusLogic/sof-linux/commits/topic/asus-UX5406SA/ correctly detects this laptop and sets the quirk? @dantmnf ? |
|
Confirmed that with 3 patches in this thread I can get it working without extra kernel/module parameters |
|
@dantmnf Thanks |
|
Sorry for the silly question, but what "3 patches" are you referring to? Is it the patch of #5301? I'm dealing with the same issue on the same laptop, but for me the internal mic only doesn't work if there is a bluetooth headphone connected (not sure if related to this), even if the headphone is not selected as input, only as output. |
|
It works for me too! |
|
Just following up from an aside with (at least) @bardliao and @rfvirgil this morning, I've been having less success... If I have a kernel at And build some topologies at The on the ux5406 Then I can see I think we should have all the necessary bits in the trees now, but as an insanity test adding the quirk in the guide didn't help either For reference, the normal quirks on this platform is only -Simon Edit; |
|
@simontrimmer I think the issue is that the "snd_soc_sdw_utils:asoc_sdw_init_dai_link: sof_sdw sof_sdw: create dai link SDW2-Capture-SmartAmp, id 3" is missing. However, I think it is expected because the amp feedback endpoint is not added in cs35l56 adr[]. Not sure why "SDW2-Capture-SmartAmp, id 3" is created by the upstream kernel. |
|
@bardliao - Yes I'm at a loss too, if you'd like me to try anything out to gather more information I have the system ready ! |
|
the 6.14-rc1 I have on there shows these DAIs as being created (no Capture-SmartAmp in the sof-kernel or in torvalds) |
|
@bardliao Yes, we don't expect a SmartAmp-Capture dailink to be created. The match entries in soc-acpi-intel-lnl-match.c only declare the speaker endpoints. They do not declare any endpoints for the capture DAI. |
|
@simontrimmer Did you set the quirk when you tried 6.14-rc1? The SDW DMIC is still present. |
|
@bardliao No I think it would have been top-of-tree without modifications and I don't think all of the sof-linux patches have made it all the way into tagged releases yet - I'd just booted it to check whether "SDW2-Capture-SmartAmp" was being created as you'd mentioned it in a comment (and it isn't, as @rfvirgil expected) |
|
I've been working this through a bit having a play with a plucky (ubuntu 25.04) install with a today top-of-tree sof-dev kernel + alsa-ucm-conf, no overriding of quirks and I'm suspecting that in context with all the other changes the IDs in the tplg might need a tweak - I'm a little hesitant to change something that already exists, does that sound reasonable to you @bardliao ? If so I can raise a PR. -Simon |
|
@simontrimmer The change looks reasonable to me. Can you test it with the upstream kernel, too? To make sure there is no surprise. :) |
|
HI @bardliao , Hmm I don't think whatever is making it work in sof-dev has made it into Mark's branch yet - I just tried 6.14rc3 and boonie's for-next and for-linus and they do not pick the correct topology. No work: Does work: (and has for a while, at least from when i posted last week) -Simon |
|
@simontrimmer I think what missed in the Mark's branch is #5287. Could you apply it to Mark's branch and try again? |
|
Hiya @bardliao - that's it, pulling that patch into Mark's trees makes them happy with the adjusted tplg. For completeness these three picked into 6.14rc3 also work
-Simon |
|
@bardliao - I'll raise a PR for the ID changes so we have it recorded properly in github I'm trying to get a second positive verification of the change - maybe @dantmnf or @Wachamuli could try Linus' tree with those three patches and adjusted topology? There's a different product that might load this topology, I'm working to get its custodian to try this change too. -Simon |
Yes they are the 3 patches mentioned in my previous comment. I applied them to stable 6.12 branch, with topology in #5325 (comment) I can't do further tests now because my device is in RMA process for fan issues. |
|
@dantmnf I assume you have seen https://github.com/dantmnf/zenbook-s14-linux?tab=readme-ov-file#microphone-array-dmic and thesofproject/sof#9834 |
|
@dantmnf I think there is some confusion around overriding the quirks - we are trying to solve the issue without forcing them to values as we're finding the natural IDs don't match up.... |
|
@simontrimmer I think 5,6,7 should be the correct IDs for HDMI, matching existing UCM conf: https://github.com/alsa-project/alsa-ucm-conf/blob/c3314b9ca29861d19164d2b3987745b7170dab06/ucm2/sof-soundwire/sof-soundwire.conf#L167-L169 I just copied them from No idea about DMIC IDs, seems they are not important for host DMIC: https://github.com/alsa-project/alsa-ucm-conf/blob/c3314b9ca29861d19164d2b3987745b7170dab06/ucm2/sof-soundwire/dmic.conf |
|
@dantmnf - cool and yes that's part of the problem and seems to be broken too - it seems that when the DMIC IDs aren't specified the defaults that get used start at 4 and aren't right for these systems, the HDMI IDs then follow on consecutively. Whilst looking at that I noticed that it declared the SDW_DMIC_STREAM which isn't right either... Pushed this for a Cirrus Logic review before I raise a PR |
|
@simontrimmer Then it becomes @bardliao's initial topology, except |
|
@dantmnf Yes, we are talking about the |
|
Yes that's a good point @bardliao I'll raise that PR edit; thesofproject/sof#9842 |
|
With the 3 patches applied to kernel 6.14-rc3 and topology at thesofproject/sof@1d1b1dd, the DMIC works without issues. There is a suspicious |
|
I will close the issue as the required patches are merged. |
Describe the bug
Recording from DMIC generates a few pulses then a flat signal.
To Reproduce
Reproduction Rate
All the time
Expected behavior
Should be able to record some sound
Impact
Unusable built-in microphone
Environment
Screenshots or console output
alsa-info output for reference:
alsa-info.txt
P.S. recording from audio jack works.
The text was updated successfully, but these errors were encountered: