Repository navigation
[BUG] No Audio - Built-in speakers silent on MSI Stealth 16 AI+ (Intel Panther Lake / Dual RT1320 SoundWire) #5925
Description
Describe the bug:
- No audio output from internal built-in speakers on an MSI Stealth 16 AI+ B3WH (Intel Panther Lake platform) running on Bazzite and CachyOS (Linux Distros).
- Previously, the speakers works on Windows 11.
- The kernel fails to find a matching SoundWire machine driver for the ACPI configuration reported by the hardware:
- Link 2: Dual Realtek ALC1320 Smart Amps (mfg_id 0x025d, part_id 0x1320)
- Link 3: Realtek ALC713 Headset Codec / DMIC (mfg_id 0x025d, part_id 0x0713)
As a result, the driver falls back to default function topologies and loads intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg. Because this loaded topology binary is configured for a single amplifier rather than the dual ALC1320 setup on this motherboard (cfg-amp:2), the physical speaker amplifiers are not driven properly, resulting in complete silence from internal speakers.
Workarounds / Diagnostics Attempted:
- Attempted kernel arguments (snd_intel_dspcfg.dsp_driver=3, snd_sof_intel_hda_common.sof_debug=1, snd_sof_sdw.quirk=*).
- Tested on Kernel 7.2.1-ogc4.1 (Bazzite/Fedora) and 7.3.0-rc1 (CachyOS).
- Inspected ALSA mixer controls (alsamixer / amixer): rt1320-1 and rt1320-2 switches/terminals (OT23 L/R) are unmuted and set to 100% volume, but no sound is produced.
- Headset 3.5mm jack works via sof-sdca-jack-id0.tplg
To Reproduce:
- Boot Linux (tested on kernels 7.2.1 and 7.3.0-rc1) on an MSI Stealth 16 AI+ B3WH (MS-2631).
- Check dmesg | grep -iE "sof|soundwire" to confirm missing machine driver entry and fallback topology loading.
- Select "Speaker" output device in KDE Settings / PipeWire.
- Play any audio file or speaker test track.
- Result: No sound is output from internal speakers.
Reproduction Rate:
- 100% (All the time across cold boots, reboots, kernel versions 7.2.1 to 7.3.0-rc1, and distributions).
Expected behavior:
- The SOF SoundWire machine driver should match the ACPI table layout for Link 2 (Dual RT1320) + Link 3 (RT713) and load a valid dual-amp SDCA topology file to drive both internal speaker amplifiers.
Impact:
- High / Showstopper for built-in speaker playback (forces reliance on headphones/Bluetooth).
Environment:
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: 7.2.1-ogc4.1.fc44.x86_64 on Bazzite & 7.3.0-rc1-1-cachyos-rc on CachyOS
- SOF Firmware Version: 2.14.1.1 (intel/sof-ipc4/ptl/sof-ptl.ri)
- Name of the topology file
- Topology Loaded (Fallback): intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
- Expected Topology: Dual-Amp topology map for Panther Lake RT1320 (Link 2) + RT713 (Link 3)
- Name of the platform(s) on which the bug is observed.
- Platform: Intel Panther Lake (sof-audio-pci-intel-ptl, PCI 8086:e328)
- System Model: MSI Stealth 16 AI+ B3WH (Board: MS-2631, BIOS: E2631IMS.10F)
Activity
bardliao commentedon Sep 8, 2026
There is no amp function on rt713 codec. It is correct to use sof-sdca-1amp-id2.tplg. The '1amp` means the amps are on 1 sdw bus which is your case.
rjbarcon commentedon Sep 8, 2026
Hi @bardliao and @abonislawski... I'm still investigating this issue with the help of ChatGPT 5.6 Sol.
Pardon me as I'm a web-app developer (typescript & dotnet) and still learning how linux & low-level system works...
@bardliao , I had originally assumed sof-sdca-1amp-id2.tplg meant there was only one physical amp, but based on the investigation I’ve been doing with help from ChatGPT 5.6 Sol, that assumption was wrong.
From what ChatGPT found by comparing my logs with the SOF/ALSA/kernel code, 1amp here refers to the amp functions being on a single SoundWire bus. That matches this laptop: both RT1320 amps are on Link 2, while the RT713 is on Link 3 for headset/mic. So I no longer think the selected topology is the issue.
We’ve also checked quite a bit of the speaker path already. Based on the captured logs:
Even with all of that, the built-in speakers are still completely silent.
The next thing ChatGPT suggested checking is the RT1320 slave DP1 configuration while playback is active, to confirm that the stream is actually enabled correctly on the codec side as well. If that also looks correct, then the remaining problem may be further inside the RT1320 output/amp initialization path rather than in the SOF topology.
Brief Summary
Based on the investigation and analysis so far:
bardliao commentedon Sep 8, 2026
Can you share the
alsa-infooutput?rjbarcon commentedon Sep 8, 2026
@bardliao this is the output from
sudo alsa-info.sh --no-uploadrjbarcon commentedon Sep 9, 2026
@bardliao @abonislawski
I did some additional investigation using the official MSI Windows 11 audio drivers for this laptop, with help from ChatGPT 5.6 Sol. The Realtek SDCA package gave us several useful clues that may help narrow down the Linux side.
References: (MSI Stealth 16 Windows 11 Drivers)
What the Windows drivers confirm
The Realtek INF files describe the same SoundWire topology that Linux detects:
This confirms that both RT1320 amplifiers are on the same SoundWire amp bus. So the
sof-sdca-1amp-id2.tplgnaming does not mean that only one physical RT1320 is being handled.The more interesting part is the Realtek Windows driver itself.
RtkSdcaXu.syscontains references to RT1320-specific functionality such as:The package also installs:
and contains MSI/subsystem-specific configuration lookups.
This suggests that Windows performs additional Realtek/MSI-specific amplifier initialization, firmware/preset loading and calibration beyond basic SoundWire enumeration.
How this helps the Linux investigation
On Linux we have already confirmed most of the upstream path:
The Linux RT1320 driver also supports machine-specific DSP/RAE data:
Those machine-specific files are currently not available for this laptop.
The Windows driver findings therefore strengthen the possibility that the remaining issue is inside the RT1320 initialization/DSP/output stage, rather than the SOF topology or Intel SoundWire transport.
Updated working root-cause ranking
These are still hypotheses, not conclusions:
sof-sdca-1amponly handles one physical RT1320So the current suspected boundary is roughly:
Next steps
rt1320-sdwcurrently performs.The Windows drivers do not directly provide a Linux fix, but they give us a useful reference implementation and point the investigation more strongly toward machine-specific RT1320 initialization, DSP firmware, RAE/calibration, or the final Class-D output state.
bardliao commentedon Sep 9, 2026
@rjbarcon I can't find any issue from the alsa-info. How did you test the speaker? Can you try
aplay -Dhw:2,2 xxx.wav -vv?rjbarcon commentedon Sep 9, 2026
@bardliao These are the tests that I have done via terminal:
Test 1:
Test 2: (No sound from the built-in speaker)
I have to stop the wireplumber & pipewire before running speaker-test
For it shows an error message: Playback open error: -16,Device or resource busy
Test 3: (No sound from the built-in speaker)
Speaker test via KDE Sound System Settings (see attached image below):
Test 4: (No sound from the built-in speaker)
Via browser (youtube, etc.) & played local music files - still no sound on speaker
Reference of this music file: https://upload.wikimedia.org/wikipedia/en/5/55/EastEnders_Theme.ogg
Test 5: (Headphone 3.5mm works)
bardliao commentedon Sep 9, 2026
Not sure why
Cannot get card index for 2. From the alsa-info, the sofsoundwire card index is 2. But anyway, it should have the same result as speaker-test -D plughw:CARD=sofsoundwire. This is not likely the SOF issue as the headphone works fine. @jack-cy-yu Can you take a look?jack-cy-yu commentedon Sep 9, 2026
@rjbarcon
Could you help dump "/proc/asound/pcm" and the register info in below path
"/sys/kernel/debug/regmap//registers", please make sure to dump register during playback.
rjbarcon commentedon Sep 9, 2026
@jack-cy-yu
First I ran
speaker-test(this test continue while doing other commands below):Then I run these commands on another terminal:
I put the output in this text file below because the text was too long (844990 lines)
rjbarcon commentedon Sep 9, 2026
@jack-cy-yu @bardliao
By the way, I watched this youtuber
Just Joshand he experienced the same issue as mine (speaker does not work)jack-cy-yu commentedon Sep 10, 2026
@rjbarcon
jack-cy-yu commentedon Sep 10, 2026
@rjbarcon
And for register dump, please dump only
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:0/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:0-sdw-mbq/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:1/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:1-sdw-mbq/registers
From your previous reg log, it seems you weren't dumping registers during playback, because a lot of registers are "XX".
3 remaining items
rjbarcon commentedon Sep 14, 2026
@bardliao @jack-cy-yu thank you for the support 🙏
New discovery: speaker state persists across Linux → Windows depending on AC power
Previous discovery: Windows → Linux → Windows causes the speakers to stop working in Windows
I first confirmed that the built-in speakers can work normally in a clean Windows 11 environment.
However, the following sequence consistently produced a different state:
Once Windows enters this state, simply rebooting or shutting down/restarting Windows does not necessarily restore the speakers.
This suggests that something initialized/configured while Linux is running may persist at the hardware/firmware level across a reboot into Windows.
Most recent discovery: removing AC power allows Windows audio to recover
I found a very interesting difference depending on whether the AC charger remains connected.
With the machine in the bad/silent state:
I then tested Linux while the AC charger was still unplugged:
So unplugging AC does not fix the Linux speaker issue itself, but it appears to prevent the bad speaker state created/left by Linux from persisting into Windows.
In contrast, when the AC charger remains connected, the behavior is:
In other words:
Possible implication
IMPORTANT NOTE:
rjbarcon commentedon Sep 16, 2026
@jack-cy-yu @bardliao
Update: Speakers now work on CachyOS but in Linux 7.1.x
I have some important new findings. I can now get the built-in speakers working on Linux but...
Current working configuration
I am currently using CachyOS (fresh/clean install) with:
The built-in speakers are currently working correctly on this kernel.
This is significant because earlier I could consistently reproduce silent speakers on Bazzite, Ubuntu, CachyOS, etc.
Non-working configuration
But speakers does NOT work on the default/stable kernel
1. Earlier Windows -> Linux behavior
Earlier in the investigation, I observed the following:
Boot Windows 11.
Reboot into Bazzite/Linux.
Reboot back into Windows 11 with the Linux NVMe still installed.
At one point, physically removing the Linux NVMe and booting Windows again restored the speakers.
I later found that a complete shutdown / cold boot could also restore Windows audio, so I no longer think removal of the Linux NVMe itself was necessarily the cause.
This initially suggested that some audio hardware/firmware state might survive an OS transition.
2. Fedora results
I later tested Fedora 44 KDE Live.
Fedora 44 KDE Live
Built-in speakers:
This was the first Linux environment where I confirmed that the internal speakers could actually work.
I then installed Fedora Kinoite 44 (because I prefer immutable system - and the desktop environment is KDE Plasma)
Initial Kinoite deployment
Kernel:
Built-in speakers:
After updating Kinoite
Kernel:
Built-in speakers:
IMPORTANT NOTE:
After this, booting back into the previously working deployment also produced inconsistent behavior. At one point the audio devices disappeared completely; later the devices returned but the internal speakers were still silent.
So this did not behave like a simple kernel-version-only regression.
3. CachyOS transition tests
I then moved to CachyOS and tested kernel 7.1.x, particularly:
I initially experienced another case where the speakers disappeared after a shutdown.
However, subsequent controlled tests gave very different results.
Test A
Results:
Test B
Results:
This is particularly interesting because Linux did not leave the speakers in a broken state for Windows.
4. Shutdown tests
I also tested shutdown instead of reboot.
Test C
Results:
Test D
I previously reproduced:
but repeating the same general scenario later resulted in:
I also tested with and without the AC charger connected. I have not found AC power alone to reliably determine whether the speakers work.
Current conclusion
The most important finding is that this does not appear to be a permanent hardware failure, and Linux is clearly capable of driving the internal speakers.
The same machine can transition through:
with the speakers remaining operational in all three boots.
At other times, very similar boot/shutdown sequences resulted in silent speakers.
Therefore, the problem now appears to involve some kind of intermittent or persistent initialization/state issue, possibly somewhere around the SoundWire / RT1320 amplifier / SOF initialization path, rather than simply:
I do not yet know which component retains or initializes that state, so I do not want to claim a specific root cause.
Current status
I will keep this system/kernel configuration for now and can collect
dmesg, SoundWire state, regmap/DAPM dumps, or other diagnostics while the speakers are in a known-working state if that would help compare it against the previous broken state.rjbarcon commentedon Sep 17, 2026
@jack-cy-yu @bardliao
Testing Scenarios
Okay now, I have done some further testing with my MSI Stealth 16 B3WH (2026) laptop:
AC Charger Connected
Battery Mode (AC Charger Disconnected)
so technically Windows (AC connected) -> Windows (Battery Mode)Linux 7.1.8-4-cachyos-hardened-ltoand the speaker has now sound in CachyOS Linux as wellAssessment Summary
bardliao commentedon Sep 17, 2026
@rjbarcon I suspect that the rt1320 Linux codec driver doesn't reset the amp properly. @jack-cy-yu Can you help on this?
jack-cy-yu commentedon Sep 17, 2026
0001-ASoC-rt1320-sdw-Add-reset-function-before-first-HW-i.txt
@rjbarcon Please try the attached patch, thanks
rjbarcon commentedon Sep 20, 2026
@jack-cy-yu @bardliao Thank you for the patch. I built and tested it, but unfortunately the internal speakers are still silent.
Patch/build Verification
ASoC: rt1320-sdw: Add reset function before first HW initializationto CachyOS Linux7.2.6-1and built a separate kernel:linux-cachyos-rt1320test 7.2.6-1sound/soc/codecs/rt1320-sdw.cand I verified thatrt1320_reset()was present in the prepared source.snd-soc-rt1320-sdw, the packages installed correctly, and I confirmed after boot that I was running:7.2.6-1-cachyos-rt1320testResult & Sanity Testing
7.2.6-1-cachyos-rt1320test.7.1.8-4-cachyos-hardened-lto7.1.8-47.1.8-4→ Shutdown → Windows 117.2.6-1-cachyos-rt1320testThe last comparison seems especially important:
Windows has consistently been able to restore working speaker output during these tests.
This makes me suspect that a warm reboot from Windows preserves some correctly initialized RT1320 state that Linux 7.1 can reuse, while a full shutdown clears that state.
However, Linux 7.2.6 still cannot produce audio even when entered through the same Windows → Restart sequence.
The reset patch may therefore be one necessary part of the fix, but there may still be another missing step later in the RT1320 initialization sequence.
Remarks
Given that this MSI is a new Panther Lake platform, I wonder whether the reset succeeds but Linux is still missing or incorrectly performing a later initialization step such as the vendor preset/MCU initialization, base-clock/PLL configuration, power state, or SoundWire initialization.
The fact that the same Windows warm-reboot state works with 7.1 but not with 7.2.6 seems like it may also be useful for identifying what changed between those kernel versions.
I'm happy to build another test kernel, add debug prints, test another patch, or collect specific RT1320/SoundWire register dumps if you can tell me what would be most useful → logs.txt
rjbarcon commentedon Oct 1, 2026
@jack-cy-yu @bardliao
Overview (Workaround)
Update: I built and tested a custom Linux 7.2.6 kernel with an additional diagnostic patch,
rt1320-preserve-first-attach-test.patch.The patch allows the existing RT1320 state to be preserved on the first SoundWire attachment instead of always applying the initialization preset. I booted with:
So, in this working case, Linux did not re-apply the RT1320 preset on the first attachment.
Rationale
IMPORTANT: I tested this because I want to boot into Linux 7.2.x with working speakers; note that I still need to boot from Windows 11 to initialize the state of RT1320 properly then I can boot to linux with speakers working
ONGOING: I'm still working on a proper solution that allows me to boot directly into Linux 7.2.x with working speakers without having to boot into Windows first.
After booting into Windows 11 first and then rebooting into the patched Linux kernel 7.2.x, the built-in speakers are working.
This is NOT the final fix. My current suspicion is that this works because Windows leaves the RT1320/ALC1320 in an already initialized, working state before Linux boots. A cold boot still fail because the amplifier would need to be initialized properly from a cold state; which is the goal I'm trying to find out...
Patch file: rt1320-preserve-first-attach-test.patch
jack-cy-yu commentedon Oct 14, 2026
@rjbarcon
Thanks a lot for the detailed testing and the diagnostic patch. This is very helpful.
Your result suggests that the issue may not be limited to the 7.2 first-attach behavior. Whenever the Linux preset is applied, the speakers are silent (cold boot, Windows warm restart → 7.2 default, and Windows warm restart → 7.2 + reset patch). When the preset is skipped and the state left by Windows is preserved, the speakers work. So we suspect the preset sequence/table itself may not be correct for this platform, and
preserve_initializationshould be treated as a temporary workaround rather than the final fix.To narrow this down, could you please collect the following?
1.
RT1320 init:log lines from your diagnostic patchPlease capture the
dev_infooutput for both amps in these three scenarios:preserve_initialization=0preserve_initialization=1e.g.
dmesg | grep "RT1320 init"We are mainly interested in
status(whether it is 0x0 after a Windows warm restart and whether the needs-initialization bit is set on cold boot) andversion.For a reliable cold boot, please:
(With AC connected, the amplifier power rails may stay on during shutdown, so it may not be a true power-on reset.)
2. Register dumps during playback
Please dump the registers while audio is playing (e.g. with
speaker-testrunning in another terminal), in two states:preserve_initialization=1Nodes:
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:0/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:0-sdw-mbq/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:1/registers
/sys/kernel/debug/regmap/sdw:0:2:025d:1320:01:1-sdw-mbq/registers
The diff between the good and bad dumps should show which registers are set by Windows but not set, or set differently, by the Linux preset. That will be the most direct clue for fixing the initialization sequence.
Thanks!
jack-cy-yu commentedon Oct 14, 2026
@rjbarcon
Another user with a similar MSI Panther Lake laptop reported above that the speakers work once the preset is applied on the first init and the MCU patch is loaded on both amps:
rt1320_load_mcu_patch: MCU patch realtek/rt1320/rt1320-patch-code-vc.bin loaded, 15232 bytes
Since 7.2 already applies the preset on the first init, we would like to check whether the MCU patch is actually loaded on your machine. If the preset is applied but the MCU patch fails to load, that could explain why 7.2 stays silent while
preserve_initialization=1(which keeps the state left by Windows) works.Could you please check the following on Linux 7.2.x without
preserve_initialization, after a cold boot (shut down, unplug AC, wait 30+ seconds, power on)?Whether the firmware file exists:
ls -l /lib/firmware/realtek/rt1320/
Whether there are any RT1320 or firmware loading messages/errors (e.g.
Direct firmware load ... failed with error -2):dmesg | grep -iE "rt1320|firmware"
The
RT1320 init:line from your diagnostic patch for both amps, so we can comparestatusandversionwith the Prestige 14 (status=0x41, version_id=2):dmesg | grep "RT1320 init"
Note: the "loaded, 15232 bytes" message above may come from the other user's own debug prints, so you may not see a success message with the stock driver. A missing firmware file or a load error is what we are looking for.
Thanks!
bardliao commentedon Oct 15, 2026
I don't think the regdump is reliable. You need to do
echo 1 > cache_bypassto bypass the cache first. Because if the codec is not reset properly, the cache value will not be aligned with the HW value.rjbarcon commentedon Oct 24, 2026
Got it @bardliao @jack-cy-yu ongoing testing this weekend
rjbarcon commentedon Oct 29, 2026
RT1320 A/B/C Diagnostic Results
Hi @jack-cy-yu @bardliao
I've completed the requested tests using my patched
7.3.0.4-cachyos-customkernel.Key findings:
id=0x6981,version=2.amp_func_status=0x61; preset applied on both amplifiers.amp_func_status=0x41; preset still applied on both amplifiers. Amplifier 1 also reportsrt1320_pde_transition_delay PDE to PS0 is NOT ready.amp_func_status=0x41; preset skipped on both amplifiers, and the speakers work.speaker-testplayback, withcache_only=Nandcache_bypass=Y.Observation:
I've attached the diagnostic logs and register dumps for comparison.
Could you please review the findings and advise on the next steps, particularly regarding preset initialization, MCU patch loading, and power-state transitions? Thank you!
rjbarcon commentedon Nov 5, 2026
MS-2631 RT1320 DSP initialization research
Source patch attached (BUILD-ONLY; NOT HARDWARE-TESTED)
Hi @jack-cy-yu @bardliao,
While waiting for your feedback on my previously posted A/B/C diagnostic results, I investigated the difference between the silent cold-boot state and the working Windows-initialized state further. I am attaching the actual experimental source patch and its supporting review files.
Additional observation: Both amplifiers showed these A/C register differences during the earlier captures:
0xC0810xFE0xFC0xC5C30xF20xF30xC5C80x030x050xC5980x040x00The working values for the first three registers also appear in
rt1320_dspfw_load_code(). This suggests investigating the advanced-DSP initialization path as well as the existing preset and MCU patch, but it does not establish the root cause.What I prepared:
ms2631-dsp-experimental.patchis a research prototype for the MSI MS-2631 (dual RT1320 VC, UIDs 0/1). It explores a per-UID DSP image and AFX/RTLSM command sequence inferred from offline analysis of the MSI Windows driver. It also contains the already-discussedpreserve_initializationworkaround and some shared driver helper/error-handling changes.Actual validation: I built
7.3.1.1-cachyos-test1(linux-cachyos-test1, CachyOS 7.3.1) with this exact patch. The RT1320 module compiled, and the kernel and headers packages were generated. The patch SHA-256 is161528a17990301056758f24caab8f9dcfc0316f5e07dab3db5f6220fa4d38b0.I have NOT installed or booted this kernel, installed the generated experimental firmware, enabled the test flag, or issued any commands to the amplifier. This is due to I may messed up the RT1320 firmware or may damage both the hardware (chip & speaker).
Safety concern: Although the new DSP test flag defaults to disabled and there are board/chip/UID checks, I have NOT verified the transfer protocol, command acknowledgment, speaker-specific R0/T0 calibration, protection limits, or failure recovery. This is not a verified fix or a patch ready for hardware testing/upstream merging.
Attached:
MS2631_RT1320_maintainer_review_SANITIZED.zip, containing the unchanged patch, README, mocked helper tests, a redacted offline firmware-preparation script, and build summary. The prior A/B/C logs are already linked above in this issue.Could you please review the approach and advise whether the RT1320 advanced DSP path is relevant here, what supported firmware/command format and speaker-protection checks are expected, and whether you would prefer a smaller diagnostics-only patch before any hardware execution? So that I may install this test patch I've been working on.
Thank you for your help.
Test Patch: MS2631_RT1320.zip
jack-cy-yu commentedon Nov 5, 2026
@rjbarcon
Could you add this in rt1320_vc_blind_write[] and try again?
static const struct reg_sequence rt1320_vc_blind_write[] = {
{ 0xe80a, 0x01 },
{ 0xc5c3, 0xf2 },
...
};
MingKangLin commentedon Nov 5, 2026
Hi @rjbarcon
I’m providing the ENC Dump Tool. Please play an audio file in Windows and capture a dump log under each of the following conditions:
Please send us the two generated .bin files, and include “Pass” or “Fail” in each filename so we can identify and compare the logs.
EncDumpTool.zip