Repository navigation
PTL: HP OmniBook X Flip 14 (103c:8ea4) - no speaker output, no SoundWire machine match (RT712 + 2x TAS2783) #5981
Description
Hardware
- HP OmniBook X Flip Laptop 14-kb0xxx, BIOS F.10
- Audio controller: Intel Core Ultra Series 3 (Panther Lake), PCI 8086:e428, subsystem 103c:8ea4
- SoundWire devices (all
Attached):- link 2:
sdw:0:2:0102:0000:01:9andsdw:0:2:0102:0000:01:c(TI, handled byslave-tas2783) - link 3:
sdw:0:3:025d:0712:01(Realtek RT712)
- link 2:
Software
- Ubuntu 26.10, kernel 7.3.0-9-generic
- linux-firmware 20260915, firmware-sof-signed 2026.09-1, alsa-ucm-conf 1.2.16.1-1ubuntu1
- PipeWire 1.6.8 / WirePlumber 0.5.17
Problem
Only "Dummy Output" is offered. The card sof-soundwire is registered, but the HiFi profile is unavailable (pw profile list: off / HiFi=no / pro-audio), so no speaker sink exists.
Kernel log
sof-audio-pci-intel-ptl 0000:00:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:
sof-audio-pci-intel-ptl 0000:00:1f.3: link 2 mfg_id 0x0102 part_id 0x0000 version 0x3
sof-audio-pci-intel-ptl 0000:00:1f.3: link 2 mfg_id 0x0102 part_id 0x0000 version 0x3
sof-audio-pci-intel-ptl 0000:00:1f.3: link 3 mfg_id 0x025d part_id 0x0712 version 0x3
sof-audio-pci-intel-ptl 0000:00:1f.3: Use SoundWire default machine driver with function topologies
acpi device:1e: function type only supported as DisCo constant
acpi device:20: function type only supported as DisCo constant
acpi device:22: SDCA function UAJ (type 6) at 0x1
acpi device:23: SDCA function SmartMic (type 3) at 0x2
acpi device:24: SDCA function HID (type 10) at 0x3
Only the jack (sof-sdca-jack-id0.tplg), mic (sof-sdca-mic-id4.tplg) and HDMI (sof-hdmi-pcm5-id5.tplg) topologies are loaded. No amp topology is loaded, although sof-sdca-2amp-id2.tplg is installed. I also see hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3.
Analysis
The ACPI tables (dump attached on request) describe the two TAS2783 amps as plain SoundWire peripherals with no SDCA speaker function: no function-type property, and the only mipi-sdca-function-* entries belong to the RT712 UAJ/SmartMic/HID functions. The generic function-topology path therefore cannot identify them as amplifiers. This looks like it needs a soc-acpi-intel-ptl-match.c entry (RT712 jack/mic + 2x TAS2783 on link 2, using sof-sdca-2amp-id2.tplg or similar), or another way to infer the amp function. I have not tested a patch.
Firmware (separate, partly worked around)
tas2783 requested 8EA4-2-0xC.bin / 8EA4-2-0x9.bin from /lib/firmware/. linux-firmware ships 8EA4-0-2-0x{9,C}.bin.zst and 8EA4-1-2-0x{9,C}.bin.zst, so the names did not match. After symlinking 8EA4-2-0x{9,C}.bin.zst to the -0- files and reloading snd_sof_pci_intel_ptl, the firmware-load errors disappeared, but there is still no speaker sink. Which of the -0-/-1- files belongs to which amp is a guess.
Also noticed
UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2471:13 from _sof_ipc4_prepare_copier_module during sof_pcm_hw_params (full trace in ubsan.txt). It may be unrelated.
Attachments: dmesg-audio.txt, ubsan.txt, soundwire.txt, alsa-info.txt, fw-links.txt, system.txt; acpi.dump (3.9 MB) available on request.
Questions
- Is a machine-driver match for this configuration already in progress?
- Which TAS2783 firmware file is correct for each amp address (0x9, 0xC)?
Downstream report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2171307
Activity
kevoriordan commentedon Oct 17, 2026
[
acpi-tables.txt
alsa-info.txt
alsa-pw.txt
dmesg-audio.txt
fw-links.txt
soundwire.txt
system.txt
tools.txt
ubsan.txt
](url)
kv2019i commentedon Oct 19, 2026
#5982 seems similar. We have not been directly in the loop w.r.t. this configuration. The driver is present in upstream, so that's good at least. @bardliao , I guess easiest path would be to add an old-style machine entry for this configuration? (for context: with standard SDCA, we should be able to set up a card based on the BIOS description, but we seem to be missing pieces here)
bardliao commentedon Oct 20, 2026
Yes, @kv2019i @kevoriordan @PatrickH1999 #5981 and #5982 are the same. We should just keep one.
It is likely the BIOS issue again.
Please see #5760 (comment).
bardliao commentedon Oct 20, 2026
@kevoriordan @PatrickH1999 While waiting for the BIOS update, could you test if #5986 help?
PatrickH1999 commentedon Oct 20, 2026
@bardliao Thanks — #5986 helps. With it the internal speaker PCM is created and plays via direct ALSA. Note: audio is not yet reaching the speakers through PipeWire/normal apps — see the last point.
HP OmniBook X 14 (board 8EA6, 2× TAS2783 on SoundWire link 2, Panther Lake), kernel 7.2.11-arch1 + this patch:
A Speaker PCM is now created — aplay -l shows card 0: sofsoundwire, device 2: Speaker (and device 35 “Deepbuffer Speaker”). Without the patch there was no speaker PCM at all, only Jack + HDMI.
dmesg now loads an amp topology that was never selected before:
loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
Direct ALSA playback to the PCM is clearly audible from the internal speakers: speaker-test -D hw:0,2 -c2 -t sine -f440 -l1
A few remaining observations (possibly separate / expected, not blockers for the patch itself):
The No SoundWire machine driver found ... Use SoundWire default machine driver with function topologies message is still printed.
It selects 1amp although there are two TAS2783 amps on link 2 — is that expected for this config, or should both be driven?
The per-amp calibration blobs are still missing (8EA6-2-0x{9,C}.bin ... error -2, fallback load), so the amp runs uncalibrated — audio is audible regardless.
Only speaker-test/direct ALSA produces sound so far. PipeWire/WirePlumber does not expose the speaker as a sink yet (pactl still shows only auto_null), so normal apps (browser, etc.) stay silent. This looks like a userspace/UCM matter rather than part of this patch, but flagging it in case it’s related.
Happy to run further tests.
PatrickH1999 commentedon Oct 20, 2026
@bardliao Update: with #5986 the internal speakers now work end-to-end, including normal apps (browser audio), after one userspace step. Summary for this board:
HP OmniBook X 14 (board 8EA6, 2× TAS2783 on SoundWire link 2, Panther Lake), kernel 7.2.11-arch1 + this patch.
Kernel side — the patch fixes it:
A Speaker PCM is created: aplay -l → card 0: sofsoundwire, device 2: Speaker. Without the patch there was no speaker PCM at all.
The amp topology now loads: loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg.
alsa.components now reports cfg-amp:2 ... spk:tas2783 hs:rt712 mic:rt712.
Direct ALSA playback is audible: speaker-test -D hw:0,2.
Userspace — why apps were initially silent (separate from this patch):
The card’s ACP/UCM profile came up as off. The only non-pro output profile (output:stereo-fallback) is marked available: no and contains only a Headphones port — no speaker port, so PipeWire fell back to a null sink.
Switching the card to the pro-audio profile exposes the raw Speaker PCM (pro-output-2); setting it as the default sink gives working speaker audio for all apps (YouTube etc.).
So the remaining gap looks like missing ALSA UCM/ACP speaker routing for the 8EA6 config, i.e. an alsa-ucm-conf matter rather than this kernel patch.
Still open / possibly expected:
No SoundWire machine driver found ... default machine driver with function topologies is still printed.
Topology is 1amp although there are two TAS2783 on link 2 — expected, or should both be driven?
Per-amp calibration blobs still missing (8EA6-2-0x{9,C}.bin ... error -2, fallback load); amp runs uncalibrated but audio is fine.
Net: #5986 is what makes the speakers reachable at all on this board. Happy to run further tests.
kevoriordan commentedon Oct 20, 2026
@bardliao Tested #5986 on HP OmniBook X Flip 14-kb0xxx (board 8EA4, BIOS F.10, 2× TAS2783 on link 2 + RT712 on link 3), Ubuntu 26.10 kernel 7.3.0-9-generic, rebuilding only
snd-sof-intel-hda-genericwith the patch.It helps, but only the left speaker plays.
loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg(plus jack-id0, mic-id4, hdmi-pcm5-id5)aplay -l: device 2 Speaker, device 35 Deepbuffer Speakercfg-amp:2 iec61937-pcm:7,6,5 spk:tas2783 hs:rt712 mic:rt712speaker-test -D hw:0,2 -c2 -s1 -t wav("Front Left") is audible from the left speaker, while-s2("Front Right") is silent. Mapping looks correct; the right channel / second amp just produces nothing. Possibly related to the 1amp topology being selected with two amps present.tas2783-{1,2} Speaker/Amp Volume) logs, for both amps (sdw:0:2:0102:0000:01:9and:01:c):amixerthen reports bothtas2783-N Speakervolumes as 0 / -100 dB, even though the left side is audible.Still seen: "No SoundWire machine driver found … function topologies", and the UBSAN shift-out-of-bounds in
ipc4-topology.c:2471.Calibration note: tas2783 requests
8EA4-2-0x{9,C}.binfrom/lib/firmware, but linux-firmware only provides8EA4-{0,1}-2-0x{9,C}.bin.zst. I symlinked8EA4-2-0x{9,C}.bin.zst→8EA4-0-2-…, which removed the load errors, but I don't know if the-0-variant is the right one for each amp.Happy to test further (e.g. a 2amp topology, or other firmware variants).
kevoriordan commentedon Oct 20, 2026
Follow-up on the #5986 test (same setup: HP OmniBook X Flip 14, 8EA4, kernel 7.3.0-9-generic + patched
snd-sof-intel-hda-generic).1. Kernel oops in SoundWire bandwidth allocation when an amp has no firmware
On one boot (it followed a hung
systemctl hibernate, so the amp may have been left in a bad state), amp:crefused playback, and WirePlumber's later stream prepare hit a divide-by-zero:So a failed
hw_paramson the amp still letspreparerun with zero-valued group params. This happened on 2 consecutive boots, then not again. The vmcore is available if useful. (The ipc4-topology UBSAN also appears with the stock driver.)2. Right speaker silent with either calibration variant
linux-firmware ships two tunings per amp for this board.
8EA4-{0,1}-2-0x{9,C}link to the8EA1-*files, whose headers readHP_Kento_14_SDW_alpha10_Stereo_AAC_20251014(-0-) and..._Stereo_FG_20251014(-1-), i.e. per-speaker-supplier variants. The driver only requests8EA4-2-0x{9,C}.bin, so neither gets picked automatically. I tested both via symlinks: no firmware-load errors either way, the left speaker plays, and the right speaker (speaker-test -D hw:0,2 -c2 -s2) is silent with both. So the missing channel doesn't look like a calibration-file issue. The 1amp topology being selected with 2 amps present seems the more likely cause.Happy to test a 2amp topology or further patches.
kevoriordan commentedon Oct 20, 2026
Correction to my last two comments: I suggested the 1amp topology might be why the right speaker is silent, but that looks wrong. In
sound/soc/intel/common/sof-function-topology-lib.c, the amp topology is named fromdai_link->num_cpus("sdca-%damp"), i.e. the number of SoundWire links carrying amps, not the number of amps. Both TAS2783s are on link 2, sosof-sdca-1amp-id2.tplgis the expected choice here.So the silent right channel is more likely in how the two amps on link 2 (uid 0x9 and 0xC) are mapped to channels, or in the second amp's setup. The
ASoC error (-16)register reads on both amps may be relevant. Happy to test a patch.bardliao commentedon Oct 21, 2026
@kevoriordan @PatrickH1999 Thanks for the testing. The "audio is not yet reaching the speakers through PipeWire/normal apps" issue might be an UCM issue. Please update the latest UCM from https://github.com/alsa-project/alsa-ucm-conf. Need @niranjanhyti 's help on the issue. And answer other questions.
kevoriordan commentedon Oct 26, 2026
@bardliao Thanks a lot for the explanations, that clears up the topology and machine-driver questions.
Update from my side (HP OmniBook X Flip 14, 8EA4, Ubuntu 7.3.0-9-generic + #5986):
tas2783.confis identical there anyway.hw:0,2with PipeWire stopped (speaker-test -D hw:0,2 -c2 -s2 -t wav), with either the AAC or the FG calibration file. Reading the amp controls logsASoC error (-16) ... soc_component_read_no_lock()on both amps (uid 0x9 and 0xC).ipc4-topology.c:2461), which is why I still see the UBSAN. I'll ask Ubuntu to pick it up.@niranjanhyti If you have a chance to look at the second amp, I'm happy to run any tests or patches. Thanks!
kevoriordan commentedon Oct 26, 2026
A possible clue for the silent right speaker, in case it helps @niranjanhyti:
speaker-test -D hw:0,2 -c2 -s2, PipeWire stopped) comes out of neither speaker.So it looks like both amps (uid 0x9 and 0xC on link 2) render channel 1, rather than the second amp being dead.
This matches what @leepaulmann described on #5904 for the ASUS PX13 (two TAS2783 on one link): the per-amp ClusterIndex (
SDW_SDCA_CTL(1, PPU21, 0x10, 0)) decides which channel each amp renders. In the Ubuntu 7.3.0-9tas2783-sdw.c,tas2783_init_seqwrites0x01to that control on every amp (line 309), and since our BIOS DisCo tables don't parse (function type only supported as DisCo constant), there's nosa_func_datainit table to set a per-amp value. If that's the cause, the second amp would need ClusterIndex set for the right channel.Happy to test a patch. I can also try writing the control on amp 0xC by hand if you can tell me the right value.
leepaulmann commentedon Oct 26, 2026
@kevoriordan Some data from the PX13 that may help narrow this down.
ClusterIndex
0x01on both amps is also what the PX13 runs on stock 7.3, and it gives correct stereo there. That's because of the stereo split in 7.3'stas2783_sdw_hw_params()(the comment mentions "mirror mode"). For a 2-channel playback stream, it narrows each amp'sch_maskto one channel by the number in its name prefix (tas2783-1→ BIT(0),tas2783-2→ BIT(1)). Each amp then gets a one-channel payload, and ClusterIndex0x01renders it.Without the split, every amp gets the full 2-channel mask. With
0x01on both, both render channel 1, so you get Left from both speakers and Right from neither, which is what you describe. So it may be worth checking that the split is in Ubuntu's 7.3.0-9 source (grep -n "mirror mode" sound/soc/codecs/tas2783-sdw.c). Your control names aretas2783-1/2, so the prefix part should match.On the test you offered: on the PX13 the ASUS ACPI init table sets
0x01on the left amp and0x04on the right amp. Stock 7.3 never applies that table; the PR #5904 fallback does. Across the two, I saw:ch_maskper amp0x010x040x04So
0x04on amp 0xC should tell the two cases apart. If it brings the right speaker back, the amps are getting the full mask and the split isn't taking effect. If amp 0xC goes silent, the split is working and the problem is somewhere else. HP may use different values from ASUS, so this is a hint, not a known-good setting for 8EA4.The
ASoC error (-16)reads on the volume controls are a separate issue: the regcache is dropped while the amp is runtime suspended. That's being discussed on linux-sound in Matthew Schwartz's series "ASoC: tas2783-sdw: volume and firmware load fixes". It shouldn't affect channel mapping.Disclosure: I worked through this with AI assistance (Claude Code). The PX13 results are from my machine, checked by ear and in the kernel log.
kevoriordan commentedon Oct 26, 2026
Good news: HP BIOS F.11 fixes this on the OmniBook X Flip 14 (8EA4), with no kernel patch needed.
After updating from F.10 to F.11 (dated 06/23/2026):
function type only supported as DisCo constantmessages are gone. Both amps now parse asSDCA function SmartAmp (type 1) at 0x1, and tas2783 logsFound Smart Amp function at index 0for 0x9 and 0xC.sof-sdca-1amp-id2.tplgloads, and PipeWire's HiFi profile shows the Speaker sink.speaker-test -c2 -t wav, checked by ear). So the silent right speaker on F.10 was the missing per-amp ACPI init table, as suspected. Thanks for pointing to the BIOS fix, @bardliao.Remaining, for anyone landing here:
8EA4-2-0x{9,C}.bin, while linux-firmware ships8EA4-{0,1}-2-0x{9,C}(AAC/FG speaker-supplier variants, see [BUG] HP OmniBook X Flip 16 (board 8EA2, ACP 7.0): tas2783 requests firmware names that linux-firmware does not ship #5957 / bugzilla 222079). I'm using symlinks to the FG files. Without them, the amps reporterror playback without fw download.@PatrickH1999 it may be worth checking HP for a BIOS update for 8EA6 too.
I'm happy for this to be closed as fixed by BIOS, or kept open for the firmware naming. Whichever you prefer. Thanks all for the help!