Announcement

**claydoh** · Sep 21, 2026, 09:51 PM

Originally posted by Ostego View Post

attempted Kernal patch /sound/soc/intel/common/soc-acpi-intel-ptl-match.c - Still

Originally posted by Ostego View Post

After kernel rebuilt and reboot still recieving same result

rebuilding what, how, and why? What is the output from?

My guess is the hardware is too shiny new (out in the wild for only a number of months(?), and is $$$), and no one has figured this all out yet. LLMs still may be lagging behind in terms of up-to-date Linux things.

May need to check out a bleeding edge, more ultra-current distro (aka Arch-like or other rolling style) as it may fare better with current kernels, firmware, Alsa, UCMs, etc.

**Ostego** · Sep 21, 2026, 10:12 PM

I did a Kernel-table modification on soc-acpi-intel-ptl-match.c to make the PTL match my MSI laptop. I did several edits and rebuilt via make -j$(nproc) M=sound/soc/intel/common and sudo cp sound/soc/intel/common/snd-soc-acpi-intel-match.ko \
$(modinfo -n snd_soc_acpi_intel_match)

sudo depmod -a

The hardware is definatly too shiny but was hoping maybe the group could put it on their radar and provide a fix.

I don't want to go with another distro of linux due to me specifically using the 24.04 of Kubuntu since it is optimized for Pixinsight. I do alot of astrophotography in my spare time.

**claydoh** · Sep 22, 2026, 12:16 AM

That's too deep for this old fart.

You more likely need a more current kernel version as well as support stuff. With SOF audio, iirc the UCM files are important, too. And the firmware probably needs updating as well.
Trying a live version of an up to date Arch based distro is an easy way to check if that alone gets your audio working, and might point to what you need.

You can get newer kernels in *buntu, but the rest of the Audio stack I do not know.

**Snowhog** · Sep 22, 2026, 07:49 AM

I would reinstall 26.04 so you are back to 'stock' without the kernel mucking. Then review the following Google AI answer.

Because this issue persists across Fedora 44, Kubuntu 26.04, and Kubuntu 24.04, the problem is not a simple configuration bug. It is a known hardware integration issue where the Linux kernel fails to map the internal amplifier pins (usually Realtek ALC897 or similar) or the Intel Smart Sound Technology (SST) / Sound Open Firmware (SOF) digital microphone arrays used in modern MSI Raider laptops.

When the sound bar moves in your volume mixer but no audio comes out of the physical speakers, it means Linux thinks it is sending sound to the right place, but the hardware amplifier remains unpowered or unrouted.

Step 1: Force Intel DMIC/SST Detection

Modern laptops route the internal microphone and speakers through Intel's digital microphone (DMIC) subsystem, which frequently breaks on Linux. You can force the traditional Intel HDA fallback driver to see if it wakes the hardware up.

Open your terminal (Ctrl + Alt + T).
Open the GRUB configuration file:

sudo nano /etc/default/grub
Look for the line starting with GRUB_CMDLINE_LINUX_DEFAULT.
Append snd_hda_intel.dmic_detect=0 inside the quotes. It should look something like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash snd_hda_intel.dmic_detect=0"
Save and exit (Press Ctrl + O, Enter, then Ctrl + X).
Update your bootloader so the changes take effect:
- For Kubuntu: sudo update-grub
- For Fedora: sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Reboot your laptop.

Step 2: Clear Corrupted PipeWire/WirePlumber Cache

Both Fedora 44 and modern Kubuntu releases utilize PipeWire and WirePlumber to manage audio routing. If the system state gets confused during installation or kernel upgrades, it can permanently mute the local node.

Purge the cached state file using this script block:

rm -rf $HOME/.local/state/wireplumber/* systemctl --user restart wireplumber pipewire pipewire-pulse

Test your audio immediately after running this to see if the mapping resets.

Step 3: Use ALSA-Tools to Force Pins (If Step 1 & 2 fail)

If you get audio through headphones but nothing through the main laptop speakers, the speaker pins are mismapped.

Install the ALSA tools GUI:
- Kubuntu: sudo apt install alsa-tools-gui
- Fedora: sudo dnf install alsa-tools
Launch the utility from your terminal: bash

sudo hdajackretask
Select your Realtek card from the drop-down menu at the top.
Check the box for "Show unconnected pins".
Look for overrides related to Internal Speaker. You may need to manually change an unassigned pin to Internal Speaker (Front) or Internal Speaker (Back) to force the laptop's physical amplifier to turn on.
Click "Apply now"

to test, and if it works, click "Install boot override" to make it permanent.

To narrow this down further, let me know:

When you run lspci -v | grep -A7 -i "audio", what audio controller models does your system list?
Do wired headphones plugged into the audio jack work, or is everything completely dead?

Knowing this will tell us if the issue is a missing firmware blob or an amplifier pin routing layout error.

**Ostego** · Sep 22, 2026, 11:40 AM

Tried Step 1 and 2 on both Fedora and Kubuntu 26.04. I went through a days each with the google Gemini. I believe I used the ALSA tools but I'll try again and post what I'm seeing. I'll install 26.04 to stick with the newest kernel build. I believe my realtek card wouldn't populate on the ALSA tools but I'll confirm. Thanks more to follow.

**Ostego** · Sep 22, 2026, 02:55 PM

Originally posted by claydoh View Post

That's too deep for this old fart.

You more likely need a more current kernel version as well as support stuff. With SOF audio, iirc the UCM files are important, too. And the firmware probably needs updating as well.
Trying a live version of an up to date Arch based distro is an easy way to check if that alone gets your audio working, and might point to what you need.

You can get newer kernels in *buntu, but the rest of the Audio stack I do not know.

I've updated the firmware and pulled new kernels namely 7.0.0. I modified UCM files multiple times.

Sounds like a few of you are using AI like I have been doing the past 3-4 days. I've used AI for Fedora, 26.04 on a clean install and here on 24.04 all which yielded no sound. I've resorted to using ChatGPT which led me down the UCM modification and modding the kernel and some other tables for the past 2 days. I think this hardware being so new I may just have to wait on a fix from the devs.

I'll do a test on an Arch based linux distro and see if the issue persists. I've also traded this laptop for the legion 9i with almost the same specs. The audio worked fine out of the box but I went back to the Raider due to the price.

I've also pulled the newest kernel builds and followed the AI on how to do this modding the UCM and several other conf files to no avail

**Ostego** · Sep 22, 2026, 03:26 PM

Originally posted by Snowhog View Post

I would reinstall 26.04 so you are back to 'stock' without the kernel mucking. Then review the following Google AI answer.

Because this issue persists across Fedora 44, Kubuntu 26.04, and Kubuntu 24.04, the problem is not a simple configuration bug. It is a known hardware integration issue where the Linux kernel fails to map the internal amplifier pins (usually Realtek ALC897 or similar) or the Intel Smart Sound Technology (SST) / Sound Open Firmware (SOF) digital microphone arrays used in modern MSI Raider laptops.

When the sound bar moves in your volume mixer but no audio comes out of the physical speakers, it means Linux thinks it is sending sound to the right place, but the hardware amplifier remains unpowered or unrouted.

Step 1: Force Intel DMIC/SST Detection

Modern laptops route the internal microphone and speakers through Intel's digital microphone (DMIC) subsystem, which frequently breaks on Linux. You can force the traditional Intel HDA fallback driver to see if it wakes the hardware up.

Open your terminal (Ctrl + Alt + T).
Open the GRUB configuration file:

sudo nano /etc/default/grub
Look for the line starting with GRUB_CMDLINE_LINUX_DEFAULT.
Append snd_hda_intel.dmic_detect=0 inside the quotes. It should look something like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash snd_hda_intel.dmic_detect=0"
Save and exit (Press Ctrl + O, Enter, then Ctrl + X).
Update your bootloader so the changes take effect:
- For Kubuntu: sudo update-grub
- For Fedora: sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Reboot your laptop.

Step 2: Clear Corrupted PipeWire/WirePlumber Cache

Both Fedora 44 and modern Kubuntu releases utilize PipeWire and WirePlumber to manage audio routing. If the system state gets confused during installation or kernel upgrades, it can permanently mute the local node.

Purge the cached state file using this script block:

rm -rf $HOME/.local/state/wireplumber/* systemctl --user restart wireplumber pipewire pipewire-pulse

Test your audio immediately after running this to see if the mapping resets.

Step 3: Use ALSA-Tools to Force Pins (If Step 1 & 2 fail)

If you get audio through headphones but nothing through the main laptop speakers, the speaker pins are mismapped.

Install the ALSA tools GUI:
- Kubuntu: sudo apt install alsa-tools-gui
- Fedora: sudo dnf install alsa-tools
Launch the utility from your terminal: bash

sudo hdajackretask
Select your Realtek card from the drop-down menu at the top.
Check the box for "Show unconnected pins".
Look for overrides related to Internal Speaker. You may need to manually change an unassigned pin to Internal Speaker (Front) or Internal Speaker (Back) to force the laptop's physical amplifier to turn on.
Click "Apply now"

to test, and if it works, click "Install boot override" to make it permanent.

To narrow this down further, let me know:

When you run lspci -v | grep -A7 -i "audio", what audio controller models does your system list?
Do wired headphones plugged into the audio jack work, or is everything completely dead?

Knowing this will tell us if the issue is a missing firmware blob or an amplifier pin routing layout error.

I did this on 24.04 anyway just to see but got similar results like I did on the 26.04. I get for codecs Nvidia GPU ap HDMI/DP and Intel Meteor Lake HDMI. Everything shows Digital out, HDMI

01:00.1 Audio device: NVIDIA Corporation Device 22e9 (rev a1)
Subsystem: NVIDIA Corporation Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 17, IOMMU group 13
Memory at 84080000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

--
80:1f.3 Multimedia audio controller: Intel Corporation Device 7f50 (rev 10)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 14fb
Flags: bus master, fast devsel, latency 32, IRQ 219, IOMMU group 22
Memory at 8000210000 (64-bit, non-prefetchable) [size=16K]
Memory at 8000000000 (64-bit, non-prefetchable) [size=2M]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_sof_pci_intel_mtl, snd_hda_intel

**Snowhog** · Sep 22, 2026, 03:27 PM

Originally posted by Ostego View Post

almost the same specs

Isn't the same as 'exactly the same specs'.

**Ostego** · Sep 22, 2026, 04:30 PM

Originally posted by Snowhog View Post

Isn't the same as 'exactly the same specs'.

I'm talking about the intel processor and GPU mainly. Other than that the 2 difference are the 64 GB of ram and 2TB drive the lenovo which don't have any bearing on the audio device. I never said exactly the same specs.

UPDATE

Kali linux, Manjaro, and CachyOS all have the exact same audio issue. Shows a dummy output and no sound so Arch based distros have the same issue

**Ostego** · Sep 22, 2026, 07:38 PM

## 1. HARDWARE IDENTIFICATION

Observed

- DMI identifies the machine as Micro-Star International Raider 16 Max HX B2WI, product revision REV:1.0; motherboard MS-2651, revision REV:1.0.
- BIOS vendor/version/date: American Megatrends International, E2651IMS.113, 08/26/2026.
- CPU: Intel Core Ultra 9 290HX Plus, family 6, model 198.
- Kernel: 7.0.0-34-generic, Ubuntu build #34~24.04.1-generic.
- Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.0-34-generic root=… ro quiet splash vt.handoff=7.

These came from sysfs DMI fields, lscpu, uname -a, and /proc/cmdline.

## 2. AUDIO PCI DEVICE

There are two PCI audio-class devices:

** PCI address Device Vendor/device Subsystem Bound driver**
━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━
0000:80:1f.3 Intel multimedia audio controller 8086:7f50, rev 10 MSI 1462:14fb sof-audio-pci-intel-mtl
────────────── ─────────────────────────────────── ─────────────────── ────────────────── ─────────────────────────
0000:01:00.1 NVIDIA audio device 10de:22e9, rev a1 NVIDIA 10de:0000 snd_hda_intel

Evidence: lspci -nnk and /sys/bus/pci/devices/0000:80:1f.3/{vendor,device,subsystem_vendor,subsystem_device,u event}. The Intel device’s PCI modalias
matches the snd_sof_pci_intel_mtl module alias.

The running kernel binds this controller through the Meteor Lake-named SOF PCI driver, despite the processor and firmware being Panther Lake generation.
That name is what the kernel reports; the evidence does not establish that the name itself causes the failure.

## 3. SOF/DSP STATUS

SOF does start. Boot messages show the Intel PCI device being initialized, the DSP being detected, the i915 audio component binding, and SOF firmware
booting successfully.

- Firmware file selected: intel/sof-ipc4/arl-s/sof-arl-s.ri
- Booted firmware/library version: 2.14.1.1
- Topology selected and loaded: intel/sof-ipc4-tplg/sof-hda-generic-idisp.tplg
- Kernel reported topology ABI 3:29:1; kernel ABI 3:23:1.

The selected topology is the generic HDA/iDisplay topology. It is consistent with the fallback machine driver in the log, rather than a speaker/amp
SoundWire topology.

The loaded modules include SOF core, PCI, Intel HDA/SoundWire support, soundwire_intel, soundwire_cadence, snd_soc_rt1320_sdw, and snd_soc_rt712_sdca.
Module metadata gives paths under /lib/modules/7.0.0-34-generic/. modinfo did not find standalone snd_soc_rt713 or snd_soc_rt1320 module names; the
observed driver names are rt712-sdca and rt1320-sdca.

## 4. SOUNDWIRE TOPOLOGY

Sysfs exposes two SoundWire masters and three attached slaves:

- Master sdw-master-0-0
- Master sdw-master-0-2
- sdw:0:0:025d:0713:01 — link 0, manufacturer 025d, part 0713, version 03; status Attached; bound to rt712-sdca.
- sdw:0:2:025d:1320:01:0 and …:1 — two link 2 instances, part 1320, version 03; both Attached; both bound to rt1320-sdca.

Each slave’s uevent includes its driver and modalias. The kernel boot log independently reports the same IDs on links 0 and 2.

The evidence therefore shows the SoundWire controller and links enumerating, and the codec/amp drivers binding. It does not show a bus-level failure to
discover or bind these components.

## 5. RT713 STATUS

A SoundWire slave with part ID 0713 is present and attached on link 0. Its sysfs DRIVER is rt712-sdca, not a driver named rt713. The kernel boot log
reports it only as manufacturer/part/version IDs.

Thus, the observed fact is a bound Realtek SDCA device with part ID 0713. Calling it RT713 is consistent with the prior identification, but the local
driver/sysfs output does not itself print the marketing model name.

## 6. RT1320 STATUS

Two SoundWire part-ID 1320 slaves are present and attached on link 2. Both bind to rt1320-sdca. This establishes that the RT1320-related SoundWire devices
are detected and bound. It does not establish that a speaker audio path was assembled or that either amplifier is producing sound.

## 7. ACPI AUDIO CONFIGURATION

Sysfs ACPI enumeration did not expose an obvious audio-codec ACPI device among the candidate INT34*/RT* HIDs examined. The ACPI dump attempt (acpidump -n
SSDT) returned no usable table output.

The boot log does provide the ACPI-reported SoundWire configuration as link/part IDs:

- link 0: 025d:0713, version 3
- link 2: two instances of 025d:1320, version 3

This is enough to establish the codec/link configuration used during matching, but not enough to inspect the underlying ACPI tables’ _ADR, _DSD, GPIO,
reset, interrupt, or other properties. The acpidump command was available, but its non-root invocation yielded no output here; I did not retry with root
privileges.

## 8. MACHINE-DRIVER MATCHING

The key boot-log sequence is:

1. SoundWire enabled … using SOF driver
2. SOF binds to the i915 audio component.
3. No SoundWire machine driver found for the ACPI-reported configuration
4. The log prints link 0 part 0713 and link 2 part 1320 twice.
5. hda codecs found, mask 4
6. using HDA machine driver skl_hda_dsp_generic now
7. SOF boots and loads the generic HDA/iDisplay topology.

That is the exact point at which the desired internal speaker machine configuration is lost: machine-table matching fails after SoundWire discovery and
before card/topology setup.

The running kernel’s exact source tree is unavailable. /usr/src/linux-source-6.8.0 is installed, but it does not match the running 7.0.0-34-generic kernel
and has no Panther Lake match implementation. Matching kernel headers and configuration exist; they indicate Panther Lake SOF support is configured, but
they do not include the relevant .c implementation. Therefore I cannot verify the exact 7.0.0-34 source table or its exact matching function from this
machine.

As a source reference only, the upstream Linux Panther Lake match table documents that SoundWire machine selection uses a link mask plus expected codec/
address entries per link, with optional machine checks; its comment says table order matters because link-mask subset matches are considered. The visible
PTL table has RT713/RT1320 arrangements on link combinations including links 1–3, and RT712/RT1320 arrangements on other combinations. The active hardware
reported here is link 0 plus link 2. That combination is not among the relevant RT713/RT1320 link layouts visible in that upstream table. This supports a
concrete likely reason for no match: the board’s actual link placement is absent from the available machine entries. However, because that is not the
exact source version running, it is not proof of the precise 7.0.0-34 table contents. Upstream Panther Lake match table

The PCI subsystem ID 1462:14fb identifies the MSI board, but the boot log’s failure is specifically reported as no match for the ACPI-reported SoundWire
configuration. The available evidence does not show that this selection is keyed directly on MSI’s PCI subsystem ID.

## 9. ALSA RESULT

ALSA exposes two cards:

- Card 0: NVIDIA HDA.
- Card 1: sof-hda-dsp, with the MSI Raider model string.

The SOF card’s PCM devices are only HDMI playback devices (HDMI1, HDMI2, HDMI3); the SOF card has no internal-speaker PCM. Its controls are HDMI/DP jack,
IEC958, ELD, and channel-map controls. The card’s reported codec is Intel Meteor Lake HDMI.

The internal speaker/amp path does not exist in the assembled SOF ALSA card. This conclusion is based on /proc/asound/pcm, /proc/asound/cards, /proc/
asound/card1/codec#2, and amixer -c 1 controls. An HDMI device is present, but it is not evidence of a working internal speaker path.

## 10. EXACT FAILURE POINT

The failure is not at PCI enumeration, SOF firmware startup, SoundWire master creation, SoundWire slave detection, or the observed RT1320/0713 driver
binds.

It is at selection of the SoundWire machine driver. The kernel reports that no machine driver matches the ACPI-reported configuration, falls back to
skl_hda_dsp_generic, loads a generic HDA/iDisplay topology, and registers only HDMI PCMs on the SOF card. Consequently, ALSA has no internal speaker PCM
or speaker/amp controls.

The exact reason this MSI board’s configuration fails the running kernel’s table cannot be proven from installed source because the source for the running
7.0.0-34-generic build is absent. The strongest evidence-based explanation is a link-layout/table mismatch: hardware reports RT part 0713 on link 0 and
two RT1320 devices on link 2, while the available upstream PTL table reference describes different RT713/RT1320 link combinations.

## 11. EVIDENCE SUPPORTING THE CONCLUSION

- Hardware identity: /sys/class/dmi/id/*, lscpu.
- PCI IDs and binding: lspci -nnk; Intel PCI sysfs uevent and driver link.
- SOF and fallback sequence: journalctl -k -b, timestamps around 19:22:32–19:22:34.
- Firmware/topology selection: same kernel journal entries.
- SoundWire status/binds: /sys/bus/soundwire/devices/*/{uevent,modalias,status} and driver symlinks.
- No speaker PCM/control path: /proc/asound/pcm, /proc/asound/cards, SOF codec dump, amixer -c 1 controls.
- Source limitation: only Linux 6.8 source is installed; running kernel is 7.0.0-34. The relevant PTL source is not in the installed 7.0 headers.
- Matching-logic reference: upstream PTL match table linked above; it is not established to be byte-for-byte the running Ubuntu kernel’s source.

## 12. REMAINING UNKNOWN INFORMATION

- The exact Panther Lake machine table and selection code compiled into kernel 7.0.0-34-generic.
- Full ACPI tables and the audio-related _ADR, _DSD, GPIO/reset, and interrupt properties. A usable unprivileged acpidump result was unavailable.
- Whether the board’s ACPI description is incomplete/incorrect, or whether the running kernel’s table simply lacks this link 0 + link 2 arrangement.
- The exact Realtek model naming for part ID 0713; local sysfs gives the ID and binds rt712-sdca.
- Whether all RT1320 instances are physically populated as expected and whether their speaker wiring/endpoint configuration matches the machine
description.

## 13. POSSIBLE FIXES — HYPOTHESES ONLY

These are investigation hypotheses, not attempted fixes:

- A kernel machine-table entry may be needed for the observed RT device IDs and link placement, potentially with an MSI board-specific match if the
existing matching rules need disambiguation.

- The ACPI description might need correction if its reported link/codec topology does not accurately represent the board.
- A suitable SOF SoundWire topology must be selected alongside any matching machine configuration; the current generic HDA/iDisplay topology contains no
internal speaker path.

**Ostego** · Sep 23, 2026, 09:13 AM

MSI RAIDER 16 MAX HX — LINUX INTERNAL AUDIO INVESTIGATION
Complete investigation summary through 2026-09-23
================================================== ============

PURPOSE
-------
This document records the Linux internal-audio investigation performed on the
MSI Raider 16 Max HX B2WI-003US OLED, including kernel/source analysis,
runtime observations, machine-driver/topology investigation, Experiment 01,
and the Codex-assisted autonomous workflow.

The objective is an actual working internal speaker system, with playback
through BOTH physical internal speakers. A kernel that merely enumerates the
codecs or exposes a PCM is not considered a success.

MACHINE / FIRMWARE
------------------
Laptop:
MSI Raider 16 Max HX B2WI-003US OLED
MSI MS-2651 REV 1.0
BIOS E2651IMS.113
BIOS date: 2026-08-26

CPU:
Intel Core Ultra 9 290HX Plus / Panther Lake generation

Intel audio PCI:
PCI address: 0000:80:1f.3
Vendor/device: 8086:7f50
MSI subsystem: 1462:14fb
Driver observed: sof-audio-pci-intel-mtl

NVIDIA audio:
PCI address: 01:00.1
Vendor/device: 10de:22e9
Driver: snd_hda_intel

OPERATING SYSTEMS TESTED
------------------------
Internal audio failure was observed across multiple Linux distributions:
- Manjaro
- Kali
- CachyOS
- Kubuntu 26.04
- Kubuntu 24.04

This made a userspace-only problem unlikely and focused the investigation on
kernel/platform support, SOF, SoundWire, ACPI machine-driver selection, and
topology.

BASELINE KERNEL
---------------
Ubuntu 24.04.5 HWE:
7.0.0-34.34~24.04.1
Upstream base: 7.0.14

Exact kernel source downloaded for investigation:
/tmp/linux-hwe-7.0-src.JIrc3p/source

BASELINE HARDWARE ENUMERATION
-----------------------------
Intel audio PCI device 0000:80:1f.3 (8086:7f50) was bound to:
sof-audio-pci-intel-mtl

The shared driver/module naming covers multiple Intel generations including
MTL/ARL/ARL-S.

SOF firmware was able to start.

SoundWire masters enumerated.

SoundWire codecs bound.

Therefore the failure was NOT simply:
- PCI enumeration
- failure to load SOF firmware
- failure to discover SoundWire masters
- failure to enumerate codecs

IMPORTANT BASELINE KERNEL MESSAGE
---------------------------------
The key kernel result was:

"No SoundWire machine driver found for the ACPI-reported configuration"

The system then fell back to:
skl_hda_dsp_generic

Generic HDA/iDisplay topology was used.

ALSA consequently exposed HDMI/iDisplay-type functionality but not the
internal speaker/amplifier playback path.

This established the primary failure point as machine-driver selection /
topology assembly rather than initial PCI/SOF/SoundWire discovery.

SOUNDWIRE HARDWARE FOUND
------------------------
RT713:
Manufacturer: 025d
Part: 0713
Version: 03
SoundWire link: 0
Modalias:
sdw:m025Dp0713v03c01
ACPI _ADR:
0x000030025d071301
Runtime node:
device:8c
Driver:
rt712-sdca

RT713 runtime firmware node information included:
mipi_revision = 0x20001

IMPORTANT:
mipi_revision=0x20001 is NOT the SDCA interface revision.
The actual SDCA property
mipi-sdw-sdca-interface-revision
remained unresolved during the investigation.

RT1320 #0:
Manufacturer: 025d
Part: 1320
Version: 03
SoundWire link: 2
Unique ID: 0
ACPI _ADR:
0x000230025d132001
Runtime node:
device:8f
Driver:
rt1320-sdca

RT1320 #1:
Manufacturer: 025d
Part: 1320
Version: 03
SoundWire link: 2
Unique ID: 1
ACPI _ADR:
0x000231025d132001
Runtime node:
device:91
Driver:
rt1320-sdca

ACPI SOUNDWIRE FUNCTIONS
------------------------
SWDA.AF01:
_ADR=1
Function: UAJ

SWDA.AF02:
_ADR=2
Function: SmartMic

SWDB.AF04:
_ADR=4
Function: SmartAmp

SWDC.AF04:
_ADR=4
Function: SmartAmp

SOURCE-CODE INVESTIGATION
-------------------------
Relevant machine source:
sound/soc/intel/common/soc-acpi-intel-arl-match.c

The ARL-S machine table was inspected.

Existing ARL-S descriptors included:

1. RT722 + RT1320:
RT722 on link 0:
_ADR 0x000030025d072201
RT1320 on link 2:
_ADR 0x000230025D132001
Topology:
sof-arl-rt722-l0_rt1320-l2.tplg

2. RT712 + RT1320:
RT712 on link 0:
_ADR 0x000030025d071201
RT1320 on link 3:
_ADR 0x000330025d132001
Topology:
sof-arl-rt712-l0-rt1320-l3.tplg
machine_check:
snd_soc_acpi_intel_sdca_is_device_rt712_vb

There was NO ARL-S machine-table entry for the exact machine:
RT713 link 0
+ RT1320 #0 link 2
+ RT1320 #1 link 2

There was also no MSI-subsystem-specific machine-table entry for:
1462:14fb

The PCI selector for 8086:7f50 selects the ARL-S SOF descriptor and its
SoundWire machine table. The subsystem ID is not itself used as the
machine-table key.

MACHINE MATCHING LOGIC
----------------------
The ARL-S selector checks:
- SoundWire link mask
- expected vs reported snd_soc_acpi_link_adr records
- machine_check when present

If nothing matches, the selector reaches the "No SoundWire machine driver
found..." path in:
sound/soc/sof/intel/hda.c

snd_soc_acpi_link_adr supports multiple devices per SoundWire link. Matching
can account for multiple identical codec part/version/manufacturer records
and unique IDs.

ASOC / SOF ARCHITECTURE INVESTIGATION
-------------------------------------
Exact Linux 7.0 source inspected in:
sound/soc/intel/boards/sof_sdw.c

create_sdw_dailink() around lines 917-923 sets:
num_cpus = hweight32(sof_dai->link_mask[stream])
num_codecs = sof_dai->num_devs[stream]

CPU DAI names are constructed from SoundWire link masks, e.g.:
SDW2 PinN

The codec map is associated with the created CPU-side link and passed into
ASoC initialization.

Important conclusion:
An amp group with RT1320 #0 and RT1320 #1 both on link 2 normally produces
ONE CPU DAI plus TWO codec DAIs, not two CPU DAIs.

ASoC supports 1:N CPU-to-codec links through:
snd_soc_dai_link_ch_map

So one CPU DAI to two codec DAIs is architecturally legal.

RT1320 driver investigation:
rt1320-aif1 = playback
rt1320-aif2 = capture

The RT1320 amplifier helper looks at multiple codecs and the DAPM routes
refer to:
rt1320-1
rt1320-2

TOPOLOGY INVESTIGATION
----------------------
The candidate PTL RT713+RT1320 topology was inspected.

Relevant topology DAIs:
alh-copier.Playback-SmartAmp.0
alh-copier.Playback-SmartAmp.1

Both use the stream name:
Playback-SmartAmp

The .0 ALH DAI:
DAI type: ALH
DAI index: 0
Direction: playback
Copier node-type token: 1980 = 16
UUID:
830ca09b12ca834a943c1fa2e82f9dda
CPC: 1647
Input pins: 1
Input formats: 3
Output formats: 1
Pipeline block: 21

The .1 ALH DAI:
DAI type: ALH
DAI index: 1
Direction: playback
Input formats: 1
Output formats: 1
Pipeline block: 22

Routes:
drc.21.1 -> alh-copier.Playback-SmartAmp.0
virtual.sdw-amp -> alh-copier.Playback-SmartAmp.1
gain.21.1 -> virtual.sdw-amp

virtual.sdw-amp is a DAPM output and is not itself a physical codec.

SOF source comments describe numbered DAI widgets as an aggregated DAI set.
The .0 member is firmware-configured; .1 exists to show the aggregation.
Some nonzero aggregate members may be skipped during firmware
prepare/setup.

IPC4 topology code counts same-stream ALH DAI widgets and can construct an
ALH multi-gateway mapping when more than one exists.

Important distinction:
topology ALH DAI index is an ALH aggregation/mapping/node concept;
it is NOT simply the SoundWire link number and is NOT automatically the
ASoC CPU-array index.

RUNTIME ALH/PDI INVESTIGATION
-----------------------------
Runtime ALH stream/PDI identifiers are built later using SoundWire link and
CPU DAI information in SOF/Intel HDA DAI code.

Relevant source areas:
sound/soc/sof/intel/hda.c
sound/soc/sof/intel/hda-dai.c
sound/soc/sof/ipc4-topology.c

A central unresolved question became:
Can one physical SoundWire link (link 2) expose two independent playback
PDI/CPU endpoints for the two RT1320 codecs?

This is important because the existing two-amp topology has two same-stream
ALH DAI widgets. If the ASoC side creates only one CPU DAI for link 2, the
topology connector can encounter two same-stream widgets but only one free
CPU DAI.

Observed/established connector behavior:
sof_connect_dai_widget() finds a BE by stream name and assigns topology
DAI widgets to CPU DAIs.
A CPU DAI stores only one widget pointer per stream.
Therefore two same-stream topology widgets cannot both consume a single
CPU DAI in the straightforward arrangement.

This motivated the possible Experiment 02: narrowly change SoundWire/SOF DAI
construction so the same physical link 2 can expose two required
CPU-side/PDI amp DAIs if the Intel SoundWire host actually supports that.

TOPOLOGY COMPARISON
-------------------
The candidate topology was byte-for-byte identical to all of these:

sof-ptl-rt713-l2-rt1320-l13.tplg
sof-ptl-rt713-l3-rt1320-l12.tplg
sof-lnl-rt713-l2-rt1320-l13.tplg

All were:
61,382 bytes

SHA256:
3a779d0059e68dbbc563ca5dc1d8c475da9b2447c301990b74 8806a80000a257

The existing PTL descriptors normally place the two RT1320 devices on
separate links. That naturally gives two CPU DAIs from hweight32(link_mask).

SAME-LINK DUAL-AMPLIFIER PRECEDENT
-----------------------------------
A PTL same-link dual-CS35L56 precedent was found.

The source contains:
cs35l56_2_lr_adr[]

with two distinct amplifier ADRs on link 2.

Another descriptor:
ptl_cs42l43_agg_l3_cs35l56_l2[]

places both amplifiers in one link-2 entry.

The installed PTL topology has SmartAmp .0/.1.

This proves same-link dual amplifiers are contemplated by the platform/source,
but it does NOT by itself prove that the current RT1320 same-link configuration
works without a DAI/PDI change.

SOF SDCA TOPOLOGY SELECTION
---------------------------
sof_sdw_get_tplg_files() selects among topology variants based on
dai_link->num_cpus.

"2amp" in this context refers to two CPU-side amplifier DAI/endpoints, not
necessarily two physical SoundWire links or two codec chips.

sof-sdca-1amp-id2:
contains SmartAmp .0 only

sof-sdca-2amp-id2:
contains SmartAmp .0 and .1

The existing PTL RT713+RT1320 descriptors put RT1320s on separate links, so
two CPU DAIs are naturally produced and the two-member topology binds
naturally.

SDCA REVISION INVESTIGATION
---------------------------
The callback:
snd_soc_acpi_intel_sdca_is_device_rt712_vb()

was inspected.

It requires:
SDCA interface revision >= 0x0801
manufacturer 0x025d
accepted part numbers including RT712/RT713/RT716/RT717
appropriate SmartMic information

The actual SDCA interface revision is obtained from the fwnode property:
mipi-sdw-sdca-interface-revision

The runtime RT713 node did not expose a directly readable value during the
initial investigation.

Attempts to inspect protected ACPI data included:
acpidump -n DSDT

This returned:
AE_ACCESS

The ACPI tables under:
/sys/firmware/acpi/tables/

were root-owned.

A noninteractive sudo test had previously failed because sudo credentials
were not cached:
sudo -n id
exit status 1

Later, interactive sudo authentication was successfully established.

No valid evidence was found that mipi_revision=0x20001 equals the required
SDCA interface revision. It does not.

EXPERIMENT 01
-------------
Experiment 01 was a descriptor-only machine-table experiment.

It modified only:
sound/soc/intel/common/soc-acpi-intel-arl-match.c

The intended purpose was to add a machine descriptor matching the actual
MSI configuration:
RT713 link 0
+ RT1320 #0 link 2
+ RT1320 #1 link 2

Build result:
SUCCESS

Kernel release:
7.0.14-PTL-RT713-EXPERIMENT-01

Kernel image:
/var/tmp/ptl-rt713-rt1320-final/BUILD/output/arch/x86/boot/bzImage

Signed modules were staged under:
/var/tmp/ptl-rt713-rt1320-final/BUILD/STAGING-SIGNED/
(exact release subdirectory was present during the build; verify after
reboot rather than assuming a path)

Patch SHA256:
fb7210f2bab02dea2320de14b703186c9b660af067784dc8b2 80eb1d41dd3d05

Kernel image SHA256:
de7acef2d7da3bed49593f037362c9e503ddaaa47d8e0b7947 1d7391ad0ff10c

vmlinux SHA256:
379843200942ea41497ca9848f5cf9b52174a4100d71356cb4 a95e07f26a3fb0

The build initially exhausted /tmp. Build output was moved to /var/tmp.

A missing gawk utility was encountered, but an existing package archive was
extracted under /var/tmp.

A signing-helper permission issue was fixed only in the temporary source
copy.

No permanent system changes were made during the build itself.

Experiment 01 compiled successfully but initially had NOT been installed or
boot-tested.

CODEX / ROOT WORKFLOW
---------------------
The user wanted Codex to autonomously perform the controlled kernel/audio
experiments, including privileged operations.

A broad autonomous Codex plan was prepared with these stages:
1. Determine RT713 SDCA revision.
2. Verify Experiment 01.
3. Install Experiment 01 side-by-side.
4. Boot it through a reversible boot entry.
5. Inspect machine match/topology/DAIs/PCM/DAPM/codec state.
6. Test actual speakers.
7. Inspect link-2 PDI capacity if required.
8. Build Experiment 02 if one CPU/two codec was insufficient.
9. Test topology alternatives.
10. Regression-test HDMI/headphone/mic/suspend.
11. Save artifacts and final conclusions.

Safety boundaries given to Codex:
- no BIOS/EC flashing
- no firmware replacement
- no destructive hardware register writes
- no disk destruction/repartitioning
- do not remove stock kernel
- do not permanently disable Secure Boot
- do not destroy stock boot entry
- do not install unknown third-party kernels
- do not perform broad unrelated upgrades
- preserve reversible boot configuration
- success requires actual physical speaker output

ROOT AUTHENTICATION
-------------------
The user first ran:

sudo -v

then:

sudo -n true && echo "ROOT AUTHENTICATED"

Result:
ROOT AUTHENTICATED

The normal shell remained:
whoami -> ostego
uid=1000(ostego)

A root shell was then established using:
sudo -i

Verification:
uid=0(root) gid=0(root) groups=0(root)

CODEX INSTALLATION
------------------
Codex was already installed for the normal user through NVM.

Command:
which codex
command -v codex

Result:
/home/ostego/.nvm/versions/node/v24.21.0/bin/codex

The path was a symlink:
/home/ostego/.nvm/versions/node/v24.21.0/bin/codex
-> ../lib/node_modules/@openai/codex/bin/codex.js

Root initially could not find it because root's PATH did not include the
user's NVM bin directory.

The proposed root environment setup was:
export NVM_DIR=/home/ostego/.nvm
export PATH="/home/ostego/.nvm/versions/node/v24.21.0/bin:$PATH"

Then:
codex --version
codex

The user eventually successfully got Codex running.

CODEX RATE-LIMIT PROMPT
-----------------------
Codex displayed:
"Approaching rate limits"
with an option to switch to gpt-5.6-luna for lower credit usage.

Because the user had approximately 5% credits remaining, the recommended
choice was:
1. Switch to gpt-5.6-luna

The long autonomous prompt was then shortened to reduce credit/context use.

REBOOT / EXPERIMENT 01 BOOT
---------------------------
The user rebooted after launching Codex/root workflow.

After reboot, Codex initially reported:
/tmp/ptl-rt713-rt1320-final does not exist in this environment

This was expected as a possibility because /tmp may be cleared during reboot.

The surviving build artifacts had previously been placed under:
/var/tmp/ptl-rt713-rt1320-final/BUILD/

Codex was instructed to search /var/tmp for surviving artifacts rather than
rebuild immediately.

IMPORTANT CURRENT BOOT RESULT
-----------------------------
After the reboot, the user manually ran:

uname -a

Result:

Linux raider16 7.0.14-PTL-RT713-EXPERIMENT-01
#1 SMP PREEMPT_DYNAMIC Wed Sep 23 08:05:27 EDT 2026
x86_64 x86_64 x86_64 GNU/Linux

This proves Experiment 01 DID boot successfully.

KDE System Settings -> Audio was also inspected visually after this reboot.

The screenshot showed:
Inactive Cards:
HDA Nvidia
Playback Streams:
Notification Sounds

There was NO visible Intel/SOF/SoundWire audio card and no internal-speaker
device in KDE/PipeWire.

This is an important runtime result:
Experiment 01 booted, but the Intel/SOF audio card was not exposed to
KDE/PipeWire.

This does NOT yet tell us whether:
- the new machine descriptor matched and later ASoC registration failed,
- the machine descriptor did not match,
- SOF failed before card registration,
- SoundWire failed,
- topology failed,
- or another kernel-level error occurred.

The exact dmesg/journal output from this Experiment 01 boot is the next
critical diagnostic.

The user was instructed NOT to reboot again and to have Codex collect:

lspci -nnk -s 80:1f.3
cat /proc/asound/cards
cat /proc/asound/pcm
lsmod | grep -Ei 'sof|soundwire|snd'
dmesg -T | grep -Ei \
'sof|soundwire|rt713|rt1320|machine driver|topology|80:1f.3|7f50|audio'
journalctl -k -b | grep -Ei \
'sof|soundwire|rt713|rt1320|machine driver|topology|80:1f.3|7f50|audio'

The purpose is to identify exactly where Experiment 01 initialization stopped.

CURRENT STATUS
--------------
KNOWN:
- Experiment 01 built successfully.
- Experiment 01 booted successfully.
- Current running kernel is:
7.0.14-PTL-RT713-EXPERIMENT-01
- KDE/PipeWire currently sees only NVIDIA HDA and no Intel/SOF card.
- Actual speaker playback has NOT yet been demonstrated.
- The stock kernel has been preserved as a fallback.
- No BIOS/EC flashing has been performed.
- No disk destruction/repartitioning has been performed.
- No permanent Secure Boot disable has been performed.
- No firmware replacement has been performed.

NOT YET ESTABLISHED:
- Whether Experiment 01's machine descriptor actually matched.
- Whether the machine driver successfully registered.
- Whether SOF firmware completed normally on Experiment 01.
- Whether SoundWire masters/codecs successfully registered on Experiment 01.
- Whether RT713's SDCA interface revision meets the callback threshold.
- Whether one CPU DAI + two RT1320 codecs can support this topology.
- Whether link 2 exposes enough PDI resources for two CPU-side amp DAIs.
- Whether a same-link dual-PDI SOF/ASoC change is required.
- Actual physical left/right speaker mapping.
- Actual physical speaker playback.

NEXT DIAGNOSTIC STEP
--------------------
Do NOT rebuild or reboot yet.

On the currently running Experiment 01 kernel, collect:

uname -a
cat /proc/cmdline
cat /proc/asound/cards
cat /proc/asound/pcm
lspci -nnk -s 80:1f.3
lsmod | grep -Ei 'sof|soundwire|snd'
dmesg -T | grep -Ei \
'sof|soundwire|rt713|rt1320|machine driver|topology|80:1f.3|7f50|audio'
journalctl -k -b | grep -Ei \
'sof|soundwire|rt713|rt1320|machine driver|topology|80:1f.3|7f50|audio'

Save complete relevant logs before making another change.

The key decision is whether the descriptor-only patch produced a machine
match and then failed during topology/ASoC registration, or whether it never
matched.

FINAL SUCCESS CRITERION
-----------------------
The investigation is NOT complete until a controlled test produces actual
audio from BOTH physical internal speakers.

A successful result must include evidence of:
- correct machine-driver selection
- RT713 binding
- both RT1320 bindings
- correct topology
- valid CPU/codec/PDI mapping
- an internal speaker playback path
- actual playback
- physical left/right speaker output

EXPERIMENT 02 — CONTINGENCY
---------------------------
If Experiment 01 shows that the one-link/two-codec architecture cannot
bind the existing two SmartAmp topology, the next experiment should be a
narrow same-link dual-PDI/dual-CPU-side-DAI change.

Candidate affected code:
sound/soc/intel/boards/sof_sdw.c

Potential supporting code to inspect:
sound/soc/sof/intel/hda.c
sound/soc/sof/intel/hda-dai.c
sound/soc/sof/ipc4-topology.c
Intel SoundWire host/PDI code
RT1320 codec driver

The change must first be justified by actual PDI/resource evidence.
Do not assume that two codecs on one link necessarily require two physical
SoundWire links or that two CPU DAIs are automatically possible.

Experiment 02 should:
- be narrowly scoped
- preserve the existing topology if possible
- preserve RT713 and RT1320 drivers
- create the required two CPU-side/PDI endpoints only if supported
- use a unique kernel release
- remain side-by-side and reversible

ARTIFACT HASHES
---------------
Experiment 01 patch:
fb7210f2bab02dea2320de14b703186c9b660af067784dc8b2 80eb1d41dd3d05

Experiment 01 kernel image:
de7acef2d7da3bed49593f037362c9e503ddaaa47d8e0b7947 1d7391ad0ff10c

Experiment 01 vmlinux:
379843200942ea41497ca9848f5cf9b52174a4100d71356cb4 a95e07f26a3fb0

Candidate PTL/LNL RT713+RT1320 topology:
3a779d0059e68dbbc563ca5dc1d8c475da9b2447c301990b74 8806a80000a257

Candidate topology size:
61,382 bytes

RELATED WEB/SOURCE RESEARCH
---------------------------
SOF architecture documentation was consulted.

Relevant SOF issues researched:
- SOF issue #10810:
ThinkPad X1 Carbon Gen 13 LNL RT713 + RT1318; digital path works
while analog headphone has issues.
- SOF issue #10401:
LNL RT713 + RT1318 topology/DMIC mismatch.
- SOF issue #11007:
WCL Dell XPS split-bus dual-CS35L56; relevant as precedent that
missing machine-driver configuration can produce partial speaker
initialization.

SOF v2.13/PTL research showed:
- PTL RT713/RT1320 topologies exist.
- sof-sdca-1amp-id2 exists.
- sof-sdca-2amp-id2 exists.

Current upstream Linux machine tables were also checked and still did not
contain the exact MSI configuration:
RT713 link 0 + two RT1320 devices on link 2.

CAVEATS
-------
1. The source tree under /tmp was temporary and disappeared across reboot.
Build artifacts had been intentionally placed under /var/tmp.
2. The exact surviving artifact path after reboot must be verified rather
than assumed.
3. The actual RT713 SDCA interface revision remains unknown.
4. The current screenshot proves the experimental kernel booted and that
KDE lacks an Intel/SOF card, but it does not identify the exact kernel
failure stage.
5. No claim of a final audio fix has been made.
6. The physical speakers have not yet been proven functional under the
experimental kernel.

END OF SUMMARY

**die.boer** · Sep 23, 2026, 11:49 AM

before mucking around more with kernel rebuilts , please post outputs of these 2

Code:

sudo dmesg | grep -A10 -B2 "No SoundWire machine driver"

Code:

sudo dmesg | grep -Ei 'soundwire|rt713|rt1320'

**Ostego** · Sep 23, 2026, 09:35 PM

Originally posted by die.boer View Post

before mucking around more with kernel rebuilts , please post outputs of these 2

Code:

sudo dmesg | grep -A10 -B2 "No SoundWire machine driver"

Code:

sudo dmesg | grep -Ei 'soundwire|rt713|rt1320'

sudo dmesg | grep -A10 -B2 "No SoundWire machine driver"
[ 3.973146] acpi device:90: SDCA function SmartAmp (type 1) at 0x4
[ 3.973239] acpi device:92: SDCA function SmartAmp (type 1) at 0x4
[ 3.978635] sof-audio-pci-intel-mtl 0000:80:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:
[ 3.978637] sof-audio-pci-intel-mtl 0000:80:1f.3: link 0 mfg_id 0x025d part_id 0x0713 version 0x3
[ 3.978639] sof-audio-pci-intel-mtl 0000:80:1f.3: link 2 mfg_id 0x025d part_id 0x1320 version 0x3
[ 3.978640] sof-audio-pci-intel-mtl 0000:80:1f.3: link 2 mfg_id 0x025d part_id 0x1320 version 0x3
[ 3.978641] sof-audio-pci-intel-mtl 0000:80:1f.3: hda codecs found, mask 4
[ 3.978643] sof-audio-pci-intel-mtl 0000:80:1f.3: using HDA machine driver skl_hda_dsp_generic now
[ 3.978644] sof-audio-pci-intel-mtl 0000:80:1f.3: NHLT device BT(0) detected, ssp_mask 0x4
[ 3.978646] sof-audio-pci-intel-mtl 0000:80:1f.3: BT link detected in NHLT tables: 0x4
[ 3.978647] sof-audio-pci-intel-mtl 0000:80:1f.3: DMICs detected in NHLT tables: 0
[ 3.983695] sof-audio-pci-intel-mtl 0000:80:1f.3: Firmware paths/files for ipc type 1:
[ 3.983698] sof-audio-pci-intel-mtl 0000:80:1f.3: Firmware file: intel/sof-ipc4/arl-s/sof-arl-s.ri

sudo dmesg | grep -Ei 'soundwire|rt713|rt1320'
[ 2.831836] sof-audio-pci-intel-mtl 0000:80:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[ 3.978635] sof-audio-pci-intel-mtl 0000:80:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:

**die.boer** · Sep 23, 2026, 11:24 PM

And output of this 1 pls

Code:

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

Announcement

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Users Viewing This Topic