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

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

[VR RS]

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

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

[VR RS]

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.

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

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

[Mukunda,Vijendar]

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

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

[Flove(HsinFu)]

+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

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

[Jack Yu]

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