Skip to content

[BUG] Internal speakers silent on Dell 16 Plus (DB16250) despite fully working driver/mixer chain #5845

Closed

Description

@EdNoepel

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

  1. Fresh install of Ubuntu 26, kernel 7.0.0, on a Dell 16 Plus DB16250.
  2. Boot the system; audio hardware is detected without errors.
  3. Attempt to play any audio (system sounds, media, etc.) through the internal speakers.
  4. 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: on
  • Pre 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: on
  • rt722 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

  1. shumingfan commented on Jul 16, 2026

    @shumingfan

    @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/

  2. EdNoepel commented on Jul 16, 2026

    @EdNoepel
    Author
    $ aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: sofsoundwire [sof-soundwire], device 0: Jack Out (*) []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: sofsoundwire [sof-soundwire], device 2: Speaker (*) []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: sofsoundwire [sof-soundwire], device 5: HDMI1 (*) [HDMI 1]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: sofsoundwire [sof-soundwire], device 6: HDMI2 (*) [HDMI 2]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: sofsoundwire [sof-soundwire], device 7: HDMI3 (*) [HDMI 3]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: sofsoundwire [sof-soundwire], device 31: Deepbuffer Jack Out (*) []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    

    Nothing relevant when sound test is running:

    $ sudo grep -rn /sys/kernel/debug/asoc/
    grep: snap/brave/652/.config/BraveSoftware/Brave-Browser/Default/IndexedDB/https_github.com_0.indexeddb.leveldb/000004.log: binary file matches
    
  3. shumingfan commented on Jul 16, 2026

    @shumingfan

    @EdNoepel
    I need the alsa-info while the command is running.
    $ alsa-info
    $ grep -rn On /sys/kernel/debug/asoc/

  4. EdNoepel commented on Jul 16, 2026

    @EdNoepel
    Author

    Sorry:
    alsa-info.txt

    $ sudo grep -rn On /sys/kernel/debug/asoc/
    grep: /sys/kernel/debug/asoc/sof-soundwire/Speaker/SDW0-Playback-SmartAmp:Playback/state: Operation not permitted
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/sdw amplifiers:1:sdw amplifiers: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/mixout.21.1:1:mixout.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/drc.21.1:1:drc.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/eqfir.21.1:1:eqfir.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/eqiir.21.1:1:eqiir.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/gain.21.1:1:gain.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/alh-copier.Playback-SmartAmp.0:1:alh-copier.Playback-SmartAmp.0: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/mixin.20.1:1:mixin.20.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/gain.20.1:1:gain.20.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/host-copier.2.playback:1:host-copier.2.playback: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/bias_level:1:On
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 DP3 Speaker Playback:1:rt722 DP3 Speaker Playback: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 DP3RX:1:rt722 DP3RX: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 FU 21:1:rt722 FU 21: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 PDE 23:1:rt722 PDE 23: On  in 0 out 0
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 SPK:1:rt722 SPK: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/bias_level:1:On
    /sys/kernel/debug/asoc/sof-soundwire/dapm/Speaker:1:Speaker: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/dapm/bias_level:1:On
    grep: /sys/kernel/debug/asoc/sof-soundwire/dapm_pop_time: Operation not permitted
    
    
  5. shumingfan commented on Jul 16, 2026

    @shumingfan

    @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.

    --- a/sound/soc/codecs/rt722-sdca-sdw.c
    +++ b/sound/soc/codecs/rt722-sdca-sdw.c
    @@ -113,6 +113,7 @@ static int rt722_sdca_mbq_size(struct device *dev, unsigned int reg)
            case 0x2000090 ... 0x2000094:
            case 0x20000b1:
            case 0x20000b4:
    +       case 0x3010000:
            case 0x3110000:
            case 0x5300000 ... 0x5300300:
            case 0x5400002:
    @@ -202,6 +203,7 @@ static bool rt722_sdca_volatile_register(struct device *dev, unsigned int reg)
            case 0x2000067:
            case 0x2000084:
            case 0x2000086:
    +       case 0x3010000:
            case 0x3110000:
            case 0x5800003:
            case 0x5810000:
    
  6. EdNoepel commented on Jul 16, 2026

    @EdNoepel
    Author

    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

  7. shumingfan commented on Jul 17, 2026

    @shumingfan

    @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?

  8. bardliao commented on Jul 17, 2026

    @bardliao
    Collaborator

    @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,0 and aplay -Dhw:0,2 simultaneously?

  9. EdNoepel commented on Jul 17, 2026

    @EdNoepel
    Author
    • Cleared the ring buffer with dmesg -C right before running speaker-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.
    • Yes; no sound from the headphone jack either. Same silent behavior as the internal speakers. Ubuntu does detect when they are connected and changes the output device accordingly.
    • The simulatenous aplay commands produced no output; they hung, presumably awaiting audio input from stdin. Also ran speaker-test -D hw:0,0 -t wav -c 2 and speaker-test -D hw:0,2 -t wav -c 2 at 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.
  10. EdNoepel commented on Jul 17, 2026

    @EdNoepel
    Author

    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.

  11. EdNoepel commented on Jul 18, 2026

    @EdNoepel
    Author

    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.

  12. EdNoepel commented on Jul 19, 2026

    @EdNoepel
    Author

    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.

  13. bardliao commented on Jul 20, 2026

    @bardliao
    Collaborator

    @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.

  14. shumingfan commented on Jul 20, 2026

    @shumingfan

    @EdNoepel
    Could you please test the attached patch?

    rt722-add-reset-codec-to-fix-no-sound-issue.patch

  15. EdNoepel commented on Jul 20, 2026

    @EdNoepel
    Author

    Here is the dmesg output: dmesg-with-sof-dyndbg.log

  16. 8 remaining items

  17. shumingfan commented on Jul 22, 2026

    @shumingfan

    Sure: rt722-regs-during-music.txt
    @EdNoepel
    This dump shows that both channels are silence and the switch controls set MUTE.
    Could you test again and set the following commands before the testing?

    $ amixer -c0 cset name='rt722 FU06 Playback Volume' 60
    $ amixer -c0 cset name='rt722 FU05 Playback Volume' 87
    $ amixer -c0 cset name='Headphone Switch' 1
    $ amixer -c0 cset name='Speaker Switch' 1
    

    Please dump registers and alsa-info while playback.
    And one more check.
    $ alsaucm -c0 reload

  18. EdNoepel commented on Jul 22, 2026

    @EdNoepel
    Author

    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 reload produced no stdout/stderr; just returned right away. No change in behavior.

  19. bardliao commented on Jul 22, 2026

    @bardliao
    Collaborator

    @EdNoepel Can you try cache bypass while dump the regmap?

    sudo su
    cd /sys/kernel/debug/regmap/sdw:0:0:025d:0722:01/
    cat registers > /tmp/registers_cache.txt
    echo 1 > cache_bypass
    cat registers > /tmp/registers_cache_bypass.txt
    echo 0 > cache_bypass
    

    Then attach both registers_cache.txt and registers_cache_bypass.txt

  20. shumingfan commented on Jul 22, 2026

    @shumingfan

    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

    @EdNoepel This dump looks unusual because the bus doesn't seem to be active.
    Some registers cannot be read, for example:

    41081180: XXXX
    

    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

  21. shumingfan commented on Jul 22, 2026

    @shumingfan

    @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.

  22. EdNoepel commented on Jul 22, 2026

    @EdNoepel
    Author

    I suspect I need to reboot to reset the bus. But without doing so, here are some results:

    $ sudo grep -rn On /sys/kernel/debug/asoc/
    [sudo: authenticate] Password:                 
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/sdw amplifiers:1:sdw amplifiers: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/mixout.21.1:1:mixout.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/drc.21.1:1:drc.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/eqfir.21.1:1:eqfir.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/eqiir.21.1:1:eqiir.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/gain.21.1:1:gain.21.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/alh-copier.Playback-SmartAmp.0:1:alh-copier.Playback-SmartAmp.0: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/mixin.20.1:1:mixin.20.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/gain.20.1:1:gain.20.1: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/host-copier.2.playback:1:host-copier.2.playback: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/0000:00:1f.3/dapm/bias_level:1:On
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 DP3 Speaker Playback:1:rt722 DP3 Speaker Playback: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 DP3RX:1:rt722 DP3RX: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 FU 21:1:rt722 FU 21: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 PDE 23:1:rt722 PDE 23: On  in 0 out 0
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/rt722 SPK:1:rt722 SPK: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/sdw:0:0:025d:0722:01/dapm/bias_level:1:On
    /sys/kernel/debug/asoc/sof-soundwire/dapm/Speaker:1:Speaker: On  in 1 out 1
    /sys/kernel/debug/asoc/sof-soundwire/dapm/bias_level:1:On
    

    rt722-mipi-registers.txt

  23. shumingfan commented on Jul 23, 2026

    @shumingfan
  24. EdNoepel commented on Jul 23, 2026

    @EdNoepel
    Author

    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?

  25. shumingfan commented on Jul 24, 2026

    @shumingfan

    @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.

  26. EdNoepel commented on Jul 24, 2026

    @EdNoepel
    Author

    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.

  27. shumingfan commented on Jul 31, 2026

    @shumingfan

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions