Repository navigation
[BUG] Internal speakers silent on Dell 16 Plus (DB16250) despite fully working driver/mixer chain #5845
Description
Possibly duplicate of two other Lunar Lake bugs reported for Lenovo laptops, but did not want to derail the conversation there.
Bug Report: Internal speakers silent on Dell 16 Plus (DB16250) despite fully working driver/mixer chain
Summary
On a Dell 16 Plus (DB16250, Intel Lunar Lake), the internal speakers produce no audio output. This is NOT a detection or mute issue — the SOF driver loads correctly, the RT722 SoundWire topology initializes without errors, every relevant ALSA mixer control is unmuted and at a normal level, and PipeWire correctly routes an active stream to the Speaker sink. Writing audio directly to the hardware PCM device (bypassing PipeWire entirely) still produces silence. This points to a firmware/kernel-level failure to actually enable the physical amplifier output, despite the driver reporting success at every stage.
System information
- Machine: Dell 16 Plus, model DB16250
- CPU/Platform: Intel Lunar Lake
- OS: Ubuntu 26
- Kernel: 7.0.0
- Audio codec: Realtek RT722 (SoundWire)
- SOF firmware: ADSPFW 2.14.1.1 (booted successfully)
- Topology loaded:
intel/sof-ipc4-tplg/sof-lnl-rt722-l0.tplg(ABI 3:29:1, Kernel ABI 3:23:1) - Sound card:
sof-soundwire/DellInc.-Dell16PlusDB16250-07V73W
Steps to reproduce
- Fresh install of Ubuntu 26, kernel 7.0.0, on a Dell 16 Plus DB16250.
- Boot the system; audio hardware is detected without errors.
- Attempt to play any audio (system sounds, media, etc.) through the internal speakers.
- No sound is produced, despite no errors being reported anywhere in the stack.
Expected behavior
Audio played through the default Speaker sink should be audible through the internal speakers.
Actual behavior
Complete silence, with no errors surfaced at the kernel, ALSA, or PipeWire/WirePlumber level.
Diagnostic steps already performed (ruling out common causes)
1. Kernel driver loads and initializes cleanly
dmesg | grep -i -E "sof|soundwire|snd"
Relevant output:
sof-audio-pci-intel-lnl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380
sof-audio-pci-intel-lnl 0000:00:1f.3: hda codecs found, mask 4
sof-audio-pci-intel-lnl 0000:00:1f.3: Firmware file: intel/sof-ipc4/lnl/sof-lnl.ri
sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: loading topology: intel/sof-ipc4-tplg/sof-lnl-rt722-l0.tplg
sof-audio-pci-intel-lnl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
sof_sdw sof_sdw: ASoC: Parent card not yet available, widget card binding deferred
No errors. Firmware boots and topology loads successfully.
2. ALSA sees the Speaker PCM device
aplay -l
card 0: sofsoundwire [sof-soundwire], device 2: Speaker (*) []
3. Every relevant mixer control is unmuted and at normal levels
amixer -c 0 contents
Key controls, all correctly enabled:
Speaker Switch: onPre Mixer Speaker Playback Volume: 45/45 (max, unmuted; dBscale-min=-90dB, step=2dB)Post Mixer Speaker Playback Volume: 45/45 (max, unmuted)Post Mixer Speaker Playback DRC switch: onrt722 FU06 Playback Volume: 67/87 (normal operating level, not muted)
No control anywhere in the chain is muted or at zero.
4. PipeWire correctly routes to the Speaker sink
wpctl status
Sinks:
* 61. Lunar Lake-M HD Audio Controller Speaker [vol: 0.68]
Streams:
106. speech-dispatcher-dummy
109. output_FL > Speaker:playback_FL [init]
110. output_FR > Speaker:playback_FR [init]
Speaker is the default sink, unmuted, with an active stream correctly routed to it.
5. Hardware-level test bypassing PipeWire entirely
speaker-test -D hw:0,2 -c 2 -t wav
Result: confirmed silence, even writing directly to the hardware PCM device with no audio server involved.
Conclusion
Every layer of the stack — kernel driver, firmware boot, topology load, ALSA mixer state, and PipeWire routing — reports success and shows a fully open, unmuted signal path. Yet no audio is physically produced, even when bypassing the desktop audio stack entirely. This strongly suggests the SOF firmware/topology for this board is not actually enabling the physical speaker amplifier output, despite reporting a successful playback stream. This may be a missing board-specific quirk or amp-enable sequence for the Dell 16 Plus DB16250 in the SOF topology or ASoC machine driver.
Activity
shumingfan commentedon Jul 16, 2026
@EdNoepel Please generate the alsa-info and dump the DAMP status while the speaker-test command is running.
$ grep -rn On /sys/kernel/debug/asoc/
EdNoepel commentedon Jul 16, 2026
Nothing relevant when sound test is running:
shumingfan commentedon Jul 16, 2026
@EdNoepel
I need the alsa-info while the command is running.
$ alsa-info
$ grep -rn On /sys/kernel/debug/asoc/
EdNoepel commentedon Jul 16, 2026
Sorry:
alsa-info.txt
shumingfan commentedon Jul 16, 2026
@EdNoepel
Please dump the codec registers while the command is running.
It will take 3~5 minutes when the first time you dump the registers, so please keep the command running.
$ cat /sys/kernel/debug/regmap/sdw:0:0:025d:0722:01/registers
Before the dump, please add the following settings to the codec driver, then update the kernel module.
EdNoepel commentedon Jul 16, 2026
Haven't done a kernel patch since I ran Gentoo over 20 years ago. SecureBoot made it difficult, but I think I got through it with some help from a clanker.
rt722-regs.txt
shumingfan commentedon Jul 17, 2026
@bardliao
I checked the register dump and found that the codec raised the silence detection flag while the test command was running.
I suspect the issue is related to the audio stream. Do you have any idea what might be causing this?
bardliao commentedon Jul 17, 2026
@EdNoepel Can you share the dmesg log in speaker playback? Does the no sound issue happen on headphone jack, too? Also, can you run
aplay -Dhw:0,0andaplay -Dhw:0,2simultaneously?EdNoepel commentedon Jul 17, 2026
dmesg -Cright before runningspeaker-test -D hw:0,2 -t wav -c 2. No relevant kernel-level activity is logged during the playback attempt — the DSP pipeline runs silently. Only output is some cruft from a browser snap I'm using to write this comment.aplaycommands produced no output; they hung, presumably awaiting audio input from stdin. Also ranspeaker-test -D hw:0,0 -t wav -c 2andspeaker-test -D hw:0,2 -t wav -c 2at the same time in separate terminals. Both opened and ran normally — standard speaker-test output on each, no errors. Still no audible sound from either.EdNoepel commentedon Jul 17, 2026
Should also clarify that speakers and headphones work properly under Windows 11.
Also, external DACs (such as USB headset and Bluetooth earphones) work properly. Problem is isolated to the internal Lunar Lake audio controller.
EdNoepel commentedon Jul 18, 2026
I updated my firmware July 15, and found an update from July 14 which did not resolve the issue. I checked again today, and there was another firmware update. Installed the update through TPM from windows and rebooted, and that resolved the issue; sound is now working in Linux. Happy to provide more details if useful; otherwise feel free to close this issue.
EdNoepel commentedon Jul 19, 2026
Oof...so I rebooted and now sound is borked in Windows -- no sound. Rebooted back into Linux, and now every time I attempt to play a test sound, I get some awful digital noise from the internal speakers which does not respond to volume control.
Cold booted, and sound works under Linux again. But if I warm reboot into Windows (still no sound) and warm reboot back into Linux, I get the digital noise.
This suggests some hardware initialization issue. Workaround for now is to cold boot each time.
bardliao commentedon Jul 20, 2026
@EdNoepel Please rename sof-dyndbg.conf.txt to sof-dyndbg.conf and put it in the /etc/modprobe.d/ folder. And get the dmesg right after reboot. I.e. Don't do playback. I would like to check is there any issue happening.
shumingfan commentedon Jul 20, 2026
@EdNoepel
Could you please test the attached patch?
rt722-add-reset-codec-to-fix-no-sound-issue.patch
EdNoepel commentedon Jul 20, 2026
Here is the
dmesgoutput: dmesg-with-sof-dyndbg.log8 remaining items
shumingfan commentedon Jul 22, 2026
Please dump registers and alsa-info while playback.
And one more check.
$ alsaucm -c0 reload
EdNoepel commentedon Jul 22, 2026
Register dump happened quickly this time. Both captured while playing a stereo WAV file in a loop:
rt722-regs-unmuted-music.txt
alsa-info.txt
alsaucm -c0 reloadproduced no stdout/stderr; just returned right away. No change in behavior.bardliao commentedon Jul 22, 2026
@EdNoepel Can you try cache bypass while dump the regmap?
Then attach both registers_cache.txt and registers_cache_bypass.txt
shumingfan commentedon Jul 22, 2026
@EdNoepel This dump looks unusual because the bus doesn't seem to be active.
Some registers cannot be read, for example:
Could you check the DAPM status while you dump?
$ sudo grep -rn On /sys/kernel/debug/asoc/
And dump the mipi-defined registers.
$ cat /sys/kernel/debug/soundwire/master-0-0/sdw:0:0:025d:0722:01/registers
shumingfan commentedon Jul 22, 2026
@EdNoepel I have the same machine now, and I'm currently debugging this issue.
If I find anything, I'll get back to you with an update.
EdNoepel commentedon Jul 22, 2026
I suspect I need to reboot to reset the bus. But without doing so, here are some results:
rt722-mipi-registers.txt
shumingfan commentedon Jul 23, 2026
@EdNoepel
Please test the v2 patch.
rt722-add-reset-codec-to-fix-sound-issue-v2.patch
EdNoepel commentedon Jul 23, 2026
Yeah, that fixes it. Sound worked in a warm reboot with the patch atop 7.0.0.27 kernel. Many thanks.
Will test cold reboot, suspend, etc and let you know if it breaks anywhere.
How long does something like this usually take to upstream?
shumingfan commentedon Jul 24, 2026
@EdNoepel Thanks for the testing.
Please share the test results with me. If there are no other issues, I will submit the patch upstream.
I'm not sure how long it will take for the patch to be merged into the stable branch.
Once it has been merged into the ASoC upstream tree, I'll share the link.
EdNoepel commentedon Jul 24, 2026
I tested suspend, cold reboot, warm reboot, no issues with any of these under Linux using the patched kernel.
Still not working under Windows following that July 17th firmware update. There's likely a lot more people looking at that. If they publish a new firmware, I'll retest the 7.0.0.27 patched kernel and a 7.0.0.28 unpatched kernel to report on behavior.
ASoC: rt722: reset codec to fix abnormal sound
shumingfan commentedon Jul 31, 2026
@EdNoepel
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=d0ecbedd6a70f2fe768d46de740265dc8a4424e3
The patch was merged.
I will close this issue now.
If there is any problem, you can reopen this issue.
ASoC: rt722: reset codec to fix abnormal sound
ASoC: rt722: reset codec to fix abnormal sound