No audio or Mic detected on MSI Raider 16 Max HX B2WI-003US

[Ostego]

And output of this 1 pls

ls -l /sys/bus/soundwire/devices/

total 0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:0:025d:0713:01 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.0/sdw-master-0-0/sdw:0:0:025d:0713:01
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:2:025d:1320:01:0 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2/sdw:0:2:025d:1320:01:0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:2:025d:1320:01:1 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2/sdw:0:2:025d:1320:01:1
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw-master-0-0 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.0/sdw-master-0-0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw-master-0-2 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2
ostego@raider16:~$

[die.boer]

total 0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:0:025d:0713:01 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.0/sdw-master-0-0/sdw:0:0:025d:0713:01
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:2:025d:1320:01:0 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2/sdw:0:2:025d:1320:01:0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw:0:2:025d:1320:01:1 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2/sdw:0:2:025d:1320:01:1
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw-master-0-0 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.0/sdw-master-0-0
lrwxrwxrwx 1 root root 0 Sep 24 01:27 sdw-master-0-2 -> ../../../devices/pci0000:80/0000:80:1f.3/soundwire_intel.link.2/sdw-master-0-2
ostego@raider16:~$

output of these 3 please

find /lib/firmware -type f \( -name '*rt713*' -o -name '*rt1320*' -o -name '*ptl*' \) | sort

apt policy firmware-sof-signed

find /lib/firmware -type f -name '*.tplg' | grep -Ei 'ptl|rt713|rt1320' | sort

so far it looks like the hardware is enumerating; the kernel simply doesn't have a machine-driver match for RT713@L0 + RT1320@L2.

[Ostego]

output of these 3 please

find /lib/firmware -type f \( -name '*rt713*' -o -name '*rt1320*' -o -name '*ptl*' \) | sort

apt policy firmware-sof-signed

find /lib/firmware -type f -name '*.tplg' | grep -Ei 'ptl|rt713|rt1320' | sort

so far it looks like the hardware is enumerating; the kernel simply doesn't have a machine-driver match for RT713@L0 + RT1320@L2.

Standby. i'm doing a clean install of Kubuntu. i've muddled in the kernal doing several rewrites. I've moved to CachyOS to diagnose on that distro as well.

[Ostego]

youSince I've moved to CachyOS to see if I could attempt to re-write similar kernal re-writes and possible fix the issue. The problem persisted. See below for a detailed summary.

https://github.com/thesofproject/sof/issues/10420

Arrow Lake-HX (Core Ultra 9 275HX) SOF firmware fails with signature validation error
0x97 - CS35L56 amplifiers non-functional


Summary of Troubleshooting Steps Taken

I systematically diagnosed the audio stack on my MSI Raider 16 Max HX B2WI running CachyOS (Linux Kernel 7.2.7-1-cachyos) with an Intel Core Ultra 9 290HX Plus (Arrow Lake-HX) processor and an NVIDIA RTX 5080 Mobile GPU.

Here is what Idiscovered and executed step-by-step:

• 🔍 Initial State (wpctl status): PipeWire recognized two audio controllers (GB203 and 800 Series ACE), but failed to detect any inputs or outputs. It defaulted to a completely silent "Dummy Output", offering only a raw "Pro Audio" profile with no mapped stereo channel streams.
• 🐧 Driver Conflict (dmesg & lspci logs): The logs revealed the kernel was experiencing an early boot race condition. The legacy snd_hda_intel driver kept greedily claiming the new 800 Series ACE audio block (80:1f.3) before the modern Sound Open Firmware (sof-audio-pci-intel-mtl) driver could map its internal DSP pipeline.
• 🛠️ Kernel & Module Adjustments:
  • I shifted the kernel command line parameters (snd_intel_dspcfg.dsp_driver=3) to explicitly mandate the use of the modern Sound Open Firmware stack.
  • I attempted a fallback down to the legacy HDA driver (dsp_driver=1), which resulted in a total audio stack crash (no soundcards found). This proved that the new 800 Series chipset completely lacks old-school physical legacy wiring routes for analog output on Arrow Lake laptops.
• 💾 Firmware Folder Loops: I ran into a directory symlink roadblock when trying to manually map firmware assets (cp: same file), confirming your system layout had linked its Arrow Lake (arl) paths directly into Meteor Lake (mtl) firmware bins.
• 📡 Current State (aplay -l): Reverting to standard DSP management successfully enabled the digital audio bridges. The kernel cleanly identifies the NVIDIA GPU HDMI streams (Card 0) and Intel PCH HDMI streams (Card 1), but the hardware topology layer for my internal laptop speakers (Realtek codec & Dynaudio amplifiers) remains entirely absent.

How I Concluded it Matches the GitHub Bug Track

My system fits the exact profile tracked in SOF Issue 10420 due to two distinct hardware traits matching my logs:

• The "HDMI-Only" Signature Profile:
  My aplay -l outputs multiple HDMI subdevices on the Intel card, but entirely skips the analog hardware layout (which usually shows up as device 0: Analog). This is the classic symptom of the Arrow Lake-HX driver bug. The Sound Open Firmware layer boots up just far enough to parse the basic PCI digital display paths, but its internal DSP topology engine fails to launch, dropping the physical speaker amp pins entirely.
• Cryptographic Signature & Bus Rejections:
  Unlike standard mobile Core Ultra chips (Meteor Lake), the desktop-class Arrow Lake-HX architecture uses a completely split power domain and distinct memory address maps (bus domain 80:00.0 instead of standard 00:00.0). The current Linux kernel tries to push the generic sof-mtl.ri or unsigned firmware profiles onto it. The Arrow Lake security hardware engine detects the lack of a specific, cryptographically signed hardware match tailored to the MSI sub-vendor motherboard ID (14fb), validation fails, and the driver freezes the internal analog amplifier lines.

Because the upstream kernel patches to cleanly whitelist and auto-initialize the signed Arrow Lake-HX tables are still trickling out, mybleeding-edge machine is caught in that bridging window where the graphics links open but the motherboard pins stay cold.


**Update**
Audio is heard via connection with HDMI. What HDMI working tells us


It confirms that at least these pieces are functional:

• PCI audio controller initialization
• kernel audio subsystem
• Intel/NVIDIA digital audio path
• ALSA PCM creation for HDMI
• enough of the SOF/ACE infrastructure to expose the digital audio functionality

So PipeWire itself is not the fundamental problem.


What it does not prove

HDMI working doesn't completely rule out the SOF firmware 0x97 problem.

The DSP can potentially get far enough for some digital paths while the SoundWire/amp topology fails.

But it makes the following hypothesis much less attractive:

"The entire Intel audio controller is dead because the firmware can't initialize."

Instead, we're looking at something closer to:

The digital audio portion works, while the machine-specific internal-speaker path isn't being assembled.

That's exactly why I want to concentrate on the machine-driver/ACPI/SoundWire matching stage rather than repeating the global DSP-driver experiments.

[die.boer]

run these on the CachyOS and post output here please

dmesg | grep -iE 'sof|soundwire|rt713|rt1320|topology|firmware|error'

find /usr/lib/firmware /lib/firmware -type f \( -name '*rt713*' -o -name '*rt1320*' -o -name '*arl*' -o -name '*ptl*' \) 2>/dev/null | sort

dmesg | grep -i 'Topology file\|loading topology\|Firmware file\|No SoundWire machine'