RE: [BUG] ASUS TUF A14 FA401EA: RT721-SDCA SoundWire speakers enumerate and stream but remain silent

[Jack Yu <jack.yu@realtek.com>]

Hi Mukunda,

Regarding to this issue, I'll send a patch to upstream later.

Regards,
Jack

> -----Original Message-----
> From: Flove(HsinFu) <flove@realtek.com>
> Sent: Tuesday, September 1, 2026 10:06 AM
> To: Mukunda,Vijendar <vijendar.mukunda@amd.com>; VR RS
> <james.vorres@gmail.com>; linux-sound@vger.kernel.org; Jack Yu
> <jack.yu@realtek.com>
> Cc: venkataprasad.potturu@amd.com; Oder Chiou <oder_chiou@realtek.com>;
> Derek [方德義] <derek.fang@realtek.com>; Dommati, Sunil-kumar
> <Sunil-kumar.Dommati@amd.com>; Syed Saba Kareem
> <syed.sabakareem@amd.com>
> Subject: RE: [BUG] ASUS TUF A14 FA401EA: RT721-SDCA SoundWire speakers
> enumerate and stream but remain silent
> 
> +more
> 
> Dear Jack:
> 
> Please help it.
> 
> -----Original Message-----
> From: Mukunda,Vijendar <vijendar.mukunda@amd.com>
> Sent: Monday, August 31, 2026 8:35 PM
> To: VR RS <james.vorres@gmail.com>; linux-sound@vger.kernel.org;
> Flove(HsinFu) <flove@realtek.com>
> Cc: venkataprasad.potturu@amd.com; Oder Chiou <oder_chiou@realtek.com>;
> Derek [方德義] <derek.fang@realtek.com>; Dommati, Sunil-kumar
> <Sunil-kumar.Dommati@amd.com>; Syed Saba Kareem
> <syed.sabakareem@amd.com>
> Subject: Re: [BUG] ASUS TUF A14 FA401EA: RT721-SDCA SoundWire speakers
> enumerate and stream but remain silent
> 
> 
> External mail : This email originated from outside the organization. Do not
> reply, click links, or open attachments unless you recognize the sender and
> know the content is safe.
> 
> 
> 
> On 8/30/26 18:43, VR RS wrote:
> > [You don't often get email from james.vorres@gmail.com. Learn why this
> > is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi,
> >
> > Follow-up with a confirmed working fix on the ASUS TUF Gaming A14
> FA401EA.
> >
> > After the FA401EA ACP70/SoundWire machine quirk was in place, the
> > RT721-SDCA card enumerated correctly and ALSA/PipeWire exposed the
> > internal Speaker and Headphone paths, but the speakers remained
> > silent.
> >
> > I decoded the board's ACPI mipi-sdca-function-initialization-table for
> > the RT721 SmartAmp path and compared it against the writes currently
> > performed by the Linux rt721-sdca driver.
> >
> > Of the 20 ACPI-supplied SmartAmp initialization records, 19 were
> > already reproduced by the existing driver sequence. The one missing
> > board-supplied write was:
> >
> >      regmap address 0x2f5d = 0x01
> >
> > This is adjacent to the existing per-function raw preset writes
> > already used by rt721_sdca_dmic_preset() and rt721_sdca_jack_preset(),
> > but there was no corresponding write in rt721_sdca_amp_preset().
> >
> > Live test:
> > - before write: 0x2f5d read back as 0x07
> > - wrote 0x2f5d = 0x01 via the SoundWire debugfs register interface
> > - readback confirmed 0x01
> > - internal speakers immediately began producing audio
> >
> > A minimal source change was then tested by adding:
> >
> >      regmap_write(rt721->regmap, 0x2f5d, 0x01);
> >
> > to rt721_sdca_amp_preset().
> >
> > The kernel was rebuilt and installed, then cold-booted with no manual
> > debugfs write. The speakers now work automatically from boot.
> >
> > Regression checks completed successfully:
> > - internal speakers: OK
> > - headphones: OK
> > - jack detection/switching: OK
> > - internal mic: OK
> > - mute/volume controls: OK
> > - suspend/resume: OK
> > - 0x2f5d restores/persists as 0x01 across resume via the existing
> > regcache path
> >
> > So the remaining speaker-silence issue is reproducibly fixed by the
> > missing RT721 SmartAmp preset write specified by this board's ACPI
> > initialization data.
> >
> > I can provide the exact patch, ACPI table decode, debugfs read/write
> > logs, or the full investigation notes if useful for upstreaming.
> ++ wider audience from amd and rtk teams.
> @Flove:  please help to comment.
> 
> 
> >
> > Thanks,
> > James
> >
> > On Sat, 29 Aug 2026 18:33:12 -0700, VR RS <james.vorres@gmail.com>
> wrote:
> >> Hi,
> >>
> >> I am reporting an audio issue on an ASUS TUF Gaming A14 FA401EA using
> the AMD ACP70 / RT721-SDCA SoundWire audio path.
> >>
> >> Hardware / OS
> >> - ASUS TUF Gaming A14 FA401EA
> >> - AMD Ryzen AI platform / ACP70 SoundWire
> >> - RT721-SDCA acting as jack + internal SmartAmp + DMIC
> >> - Arch Linux / Omarchy
> >> - Windows on the same machine plays through the internal speakers
> >> normally
> >>
> >> Kernel work tested
> >> - Stock Linux 7.1.9 did not expose the internal audio path correctly.
> >> - A custom 7.1.9-arch1-2-fa401audio build using the existing FA401EA
> SoundWire quirk lineage made ALSA/PipeWire enumerate the device correctly,
> but produced no audible output.
> >> - A follow-up 7.1.9-arch1-3-fa401audio build tested an FA401EA-specific
> non-aggregated endpoint mapping. It still produced no audible output.
> >>
> >> Current ALSA enumeration
> >> - card 1: amdsoundwire
> >> - device 0: SDW1-PIN0-PLAYBACK-SimpleJack rt721-sdca-aif1-0
> >> - device 2: SDW1-PIN1-PLAYBACK-SmartAmp rt721-sdca-aif2-2
> >>
> >> PipeWire creates both:
> >> - Audio Coprocessor Speaker
> >> - Audio Coprocessor Headphones
> >>
> >> The Speaker sink maps to hw:amdsoundwire,2 and can be selected as the
> default sink.
> >>
> >> Raw ALSA test
> >> speaker-test -D hw:amdsoundwire,2 -c 2
> >>
> >> The PCM opens successfully at 48 kHz / S16_LE / 2 channels, runs
> continuously with no xruns or errors, and alternates Front Left / Front Right,
> but there is total silence from the internal speakers.
> >>
> >> Diagnostics performed during active playback
> >> - PCM/DMA state: RUNNING
> >> - RT721 SoundWire slave/runtime state: active
> >> - ACP SoundWire manager: active
> >> - DP3 SmartAmp sink port: active bank, both stereo channels enabled
> >> - DP3 word length: 16-bit, matching the stream
> >> - DAPM path: DP3RX -> FU21/FU23 -> SPK -> Speaker, with the relevant
> >> widgets powered
> >> - Speaker mixer controls: unmuted / full playback level
> >> - RT721 driver power/mute sequencing: verified against the exact
> >> driver source and appears to execute as intended
> >> - CS31 sample-rate programming: 48 kHz path traced in the driver and
> >> live state checked
> >> - Function-unit input gain on entity 0x23 / control 0x0B: live
> >> readback is 0xFE80 on both channels, matching the ACPI
> >> mipi-sdca-function-initialization-table (approximately -1.5 dB), so
> >> this is not a muted/default-gain issue
> >> - ACPI DSDT/SSDT inspection found no separate GPIO/_DSM/WMI/EC
> >> speaker-enable sequence outside the RT721 SDCA path
> >> - Windows on the same hardware confirms the speakers/amp are
> >> physically functional
> >>
> >> Hypotheses already tested and ruled out
> >> - PipeWire routing/default-sink issue
> >> - ALSA mute/volume issue
> >> - missing DAPM route or unpowered speaker widget
> >> - incorrect sample rate
> >> - missing ACPI speaker-enable GPIO/DSM/WMI method
> >> - missing FU input-gain initialization
> >> - FA401EA endpoint aggregation mismatch (tested in a dedicated
> >> rebuild; did not restore output)
> >> - a meaningful behavioural difference in the shared RT721 vs
> >> RT722/RT712 speaker-init path was not found
> >>
> >> At this point every Linux-visible layer from PCM through SoundWire
> transport and SDCA control-plane state looks consistent during playback, yet
> the speakers remain silent. The remaining unverified area appears to be RT721
> vendor-specific analog/index-register initialization or another board-specific
> condition not visible through the standardized SDCA controls.
> >>
> >> A detailed local investigation report was generated, including the live
> register/DAPM/ACPI findings and the failed endpoint experiment. I can provide
> the full report, kernel patch, logs, ACPI tables, or any targeted register/debug
> output that would be useful.
> >>
> >> Please let me know what additional traces would be most helpful,
> particularly around RT721 vendor analog/output initialization on a
> self-contained SmartAmp topology.
> >>
> >> Thanks,
> >> James