Here is more: The DSP layer is now fully working, but there's one more error, and it's specific:
qcom-apm gprsvc:service:2:1: ASoC error (-2): at snd_soc_component_probe() on gprsvc:service:2:1 snd-x1e80100 sound: ASoC: failed to instantiate card -2 $sudo dmesg | grep -iE "firmware|request_firmware" | grep -iE "apm|q6|tplg|topology" The DSP layer is now fully working, but there's one more error, and it's specific: qcom-apm gprsvc:service:2:1: ASoC error (-2): at snd_soc_component_probe() on gprsvc:service:2:1 snd-x1e80100 sound: ASoC: failed to instantiate card -2 This is the Audio Power Manager component (a service that sits on top of the now-working DSP) failing to probe — error -2 is "file not found," so there's likely one more specific firmware/config file it's trying to load right before this. Let's find the exact filename: bash sudo dmesg | grep -iE "firmware|request_firmware" | grep -iE "apm|q6|tplg|topology" Also worth checking whether a topology file is involved — we saw a GLYMUR-CRD-tplg.bin (generic reference-board topology) sitting in the upstream Glymur firmware folder earlier tonight, which we never placed since we were focused on the DSP core itself: bash ls /lib/firmware/qcom/glymur/*tplg* 2>/dev/null ls /lib/firmware/qcom/glymur/ASUSTeK/UX3407NA/ 2>/dev/null find / -iname "*tplg*" 2>/dev/null | grep -i qcom This checks whether a topology binary (the file that maps which speakers/mics exist and how they're wired) exists anywhere, and specifically whether your device's own extracted firmware set included one (the qcom-firmware-extract output listed adspr.jsn, adsps.jsn, etc. — those might actually be the topology config in a different format, worth checking if they got placed correctly too). sudo dmesg | grep -iE "firmware|request_firmware" | grep -iE "apm|q6|tplg|topology" dantus@x2dan:~/Downloads$ sudo dmesg | grep -iE "firmware|request_firmware" | grep -iE "apm|q6|tplg|topology" [ 8.926989] qcom-apm gprsvc:service:2:1: Direct firmware load for qcom/glymur/GLYMUR-ASUS-Zenbook-A14-UX3407NA-tplg.bin failed with error -2 [ 8.926997] qcom-apm gprsvc:service:2:1: tplg firmware loading qcom/glymur/GLYMUR-ASUS-Zenbook-A14-UX3407NA-tplg.bin failed -2 Found the exact remaining gap — a topology file named specifically for your model (GLYMUR-ASUS-Zenbook-A14-UX3407NA-tplg.bin), which tells the audio subsystem how your speakers/mics are wired. This wasn't in qcom- firmware-extract's file list from that run — its supported-file list clearly hasn't caught up to include topology files yet, even though it now knows your device. Since this file wasn't extracted automatically, let's check if it actually exists in your Windows driver store and grab it manually, the same way we did before the extraction tool existed: bash sudo mkdir -p /tmp/winmount sudo mount -t ntfs-3g -o ro /dev/nvme0n1p14 /tmp/winmount find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*tplg*" 2>/dev/null This searches your actual Windows driver store for anything matching "tplg" — if the file genuinely exists there under a similar name, we can copy it directly into place: bash sudo mkdir -p /lib/firmware/qcom/glymur sudo cp "/tmp/winmount/path/to/found/file" /lib/firmware/qcom/glymur/GLYMUR-ASUS-Zenbook-A14-UX3407NA-tplg.bin sudo umount /tmp/winmount sudo reboot bash find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*zenbook*" 2>/dev/null find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*ux3407*" 2>/dev/null find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*.bin" 2>/dev/null | grep -i topo find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*glymur*" 2>/dev/null dantus@x2dan:~/Downloads$ find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*zenbook*" 2>/dev/null find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*ux3407*" 2>/dev/null find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*.bin" 2>/dev/null | grep -i topo find /tmp/winmount/Windows/System32/DriverStore/FileRepository -iname "*glymur*" 2>/dev/null /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C420D.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C420D_CMDEF.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C422A.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C422A_CMDEF.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C4249.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C4249_CMDEF.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C424D.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/myasus_splendid.inf_arm64_38c5169b898a5640/UX3407NA_QCOM_834C424D_CMDEF.icm /tmp/winmount/Windows/System32/DriverStore/FileRepository/ux3407na_315.inf_arm64_2a9077789c32b1ee /tmp/winmount/Windows/System32/DriverStore/FileRepository/ux3407na_315.inf_arm64_2a9077789c32b1ee/UX3407NA.315 /tmp/winmount/Windows/System32/DriverStore/FileRepository/ux3407na_315.inf_arm64_2a9077789c32b1ee/UX3407NA_315.cat /tmp/winmount/Windows/System32/DriverStore/FileRepository/ux3407na_315.inf_arm64_2a9077789c32b1ee/UX3407NA_315.inf /tmp/winmount/Windows/System32/DriverStore/FileRepository/ux3407na_315.inf_arm64_2a9077789c32b1ee.ini /tmp/winmount/Windows/System32/DriverStore/FileRepository/qcwlanhmt8480.inf_arm64_5f9569322239def0/bdwlan_wcn785x_2p0_ncm825_UX3407Q.elf Searching the driver store for a missing topology file. Confirmed — none of these are what we need. What we're finding is: .icm color-calibration profiles (screen color management, unrelated to audio), the ASUS keyboard/BIOS .inf/.cat driver package, and one genuinely interesting-but-irrelevant find — a Wi-Fi board file (bdwlan_wcn785x...UX3407Q.elf) for a different Qualcomm Wi-Fi chip naming scheme, not your QCC2072, and in any case not an audio file. There's no .bin/topology file anywhere in the Windows driver store matching what Linux's tplg firmware loader expects. This makes sense once you think about the underlying architecture: Windows doesn't use ALSA's topology-file concept at all — Windows audio drivers embed their routing/wiring logic directly inside proprietary driver binaries (APO/DSP effect chains) rather than as a separate extractable data file. So there's genuinely nothing sitting on the Windows partition to copy over this time — unlike the DSP firmware, Wi-Fi calibration data, etc., which all exist as standalone files Windows happens to also use. This means the topology file needs to be authored from scratch by someone who understands this exact hardware's audio routing (which codec pins connect to which speakers/mics, gain staging, etc.) — genuine engineering work, not a file-relocation problem. That's squarely something for the Debian/Ubuntu Concept maintainers or the upstream sof/asoc community to build, given they have the actual schematic/pin- mapping knowledge (or need to reverse-engineer it from the Windows driver binary itself, which is a much bigger undertaking). Let's clean up and report this precise finding back: bash sudo umount /tmp/winmount -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2167022 Title: No audio output ("Dummy Output" only) — missing ADSP/CDSP firmware for ASUS Zenbook A14 UX3407NA (Snapdragon X2 Elite) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-concept/+bug/2167022/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
