Summary
The left internal speaker channel on a Samsung Galaxy Book3 Ultra consistently crackles under Linux. The right channel works correctly.
The problem reproduces with direct ALSA hardware playback while PipeWire and WirePlumber are completely stopped. Both speakers work perfectly under Windows on the same laptop.
Hardware
| Component |
Detail |
| Laptop |
Samsung Galaxy Book3 Ultra NP960XFH-XA2BR |
| CPU |
Intel Core i9-13900H |
| Audio controller |
Intel Raptor Lake-P/U/H cAVS 8086:51ca |
| Codec |
Realtek ALC298 10ec:0298 |
| Codec/controller subsystem |
Samsung 144d:c1cc |
| Kernel driver |
sof-audio-pci-intel-tgl |
| Distribution |
openSUSE Tumbleweed 20260724 |
| Kernel |
7.1.4-1-default |
| PipeWire |
1.6.8 |
| WirePlumber |
0.5.15 |
| ALSA |
1.2.16.1 |
| SOF firmware |
2025.12.2 |
The subsystem ID is already matched by:
SND_PCI_QUIRK(0x144d, 0xc1cc,
"Samsung Galaxy Book3 Ultra (NT960XFH)",
ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS)
Symptoms
- The left speaker channel crackles during the spoken channel test.
- On openSUSE Tumbleweed, crackling is audible on both words of "Front Left."
- On a Fedora KDE live USB, the same channel crackles on "Front" but not "Left."
- The right channel works normally.
- Both internal speaker channels work perfectly in Windows.
- The problem has existed across multiple Linux versions and configurations.
- Testing from a Fedora live USB rules out accumulated openSUSE configuration or user-session state.
PipeWire-independent reproduction
PipeWire, PipeWire Pulse and WirePlumber were stopped before testing:
systemctl --user stop \
wireplumber.service \
pipewire-pulse.service \
pipewire.service \
pipewire-pulse.socket \
pipewire.socket
The standard ALSA front-left sample was then played directly through the normal hardware PCM:
speaker-test \
-D plughw:0,0 \
-c 2 \
-r 48000 \
-F S16_LE \
-t wav \
-w /usr/share/sounds/alsa/Front_Left.wav \
-l 1 \
-s 1
The command completed successfully and the left channel crackled. The hardware Speaker mixer channels were equal and unmuted. The test was repeated at an audible hardware level.
This rules out PipeWire, WirePlumber and the desktop channel-test implementation as the root cause.
Expected result
The left speaker should reproduce the sample cleanly, as it does under Windows and as the Linux right channel does.
Suspected area
The shared digital audio path appears functional because the right channel is clean. The problem seems specific to the Samsung/Realtek per-amplifier programming used by ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS.
Possible areas to investigate include:
- initialization coefficients for left-side amplifier IDs;
- amplifier enable/disable ordering;
- missing stabilization or volume-ramp delay;
- differences between the simplified Linux sequence and the Windows vendor sequence;
- amplifier state after HDA codec power transitions.
I am not claiming a particular register-level fix; assistance capturing and comparing the relevant amplifier state would be appreciated.
Related upstream work
Please let me know which additional codec dumps, dynamic-debug logs or controlled playback tests would help isolate the incorrect left-amplifier state.
Summary
The left internal speaker channel on a Samsung Galaxy Book3 Ultra consistently crackles under Linux. The right channel works correctly.
The problem reproduces with direct ALSA hardware playback while PipeWire and WirePlumber are completely stopped. Both speakers work perfectly under Windows on the same laptop.
Hardware
8086:51ca10ec:0298144d:c1ccsof-audio-pci-intel-tgl7.1.4-1-defaultThe subsystem ID is already matched by:
Symptoms
PipeWire-independent reproduction
PipeWire, PipeWire Pulse and WirePlumber were stopped before testing:
systemctl --user stop \ wireplumber.service \ pipewire-pulse.service \ pipewire.service \ pipewire-pulse.socket \ pipewire.socketThe standard ALSA front-left sample was then played directly through the normal hardware PCM:
speaker-test \ -D plughw:0,0 \ -c 2 \ -r 48000 \ -F S16_LE \ -t wav \ -w /usr/share/sounds/alsa/Front_Left.wav \ -l 1 \ -s 1The command completed successfully and the left channel crackled. The hardware Speaker mixer channels were equal and unmuted. The test was repeated at an audible hardware level.
This rules out PipeWire, WirePlumber and the desktop channel-test implementation as the root cause.
Expected result
The left speaker should reproduce the sample cleanly, as it does under Windows and as the Linux right channel does.
Suspected area
The shared digital audio path appears functional because the right channel is clean. The problem seems specific to the Samsung/Realtek per-amplifier programming used by
ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS.Possible areas to investigate include:
I am not claiming a particular register-level fix; assistance capturing and comparing the relevant amplifier state would be appreciated.
Related upstream work
[BUG] Samsung Galaxy Book2 Pro 360 no sound through speaker #4055
144d:c1ccsubsystem:ALC298 (Samsung Galaxy Book3 Ultra NP960XFH): speakers silent after s2idle resume — SOF DSP audio path broken #5730
torvalds@7e4d4b3
Please let me know which additional codec dumps, dynamic-debug logs or controlled playback tests would help isolate the incorrect left-amplifier state.