Re: [BUG] ASoC/AMD ACP70/RT721: ASUS TUF Gaming A14 FA401EA speakers silent and headphone jack buzzes on playback

[Cristian Timohi]

Hi Mark, Jack, Shengyu, all,

I performed the test Jack requested for NID 0x5f / index 0x30 on my
affected ASUS TUF Gaming A14 FA401EA.

I am including all details below because there were a few important
observations during the test.

One note before the technical details: I am not a Linux kernel/audio
developer, and this level of ASoC/SoundWire/RT721 debugging is beyond
my normal area of expertise. I am working through these tests with
ChatGPT helping me understand the driver code, build temporary
diagnostic modules, and perform the tests carefully.

I am trying to keep every experiment minimal, reversible, and verified
by readback where possible. I hope the results are still useful for
debugging the actual issue.

---

## SYSTEM

Laptop:
ASUS TUF Gaming A14 FA401EA

CPU/platform:
Ryzen AI MAX+ 392
AMD ACP 7.0

Codec:
Realtek RT721 SDCA

BIOS:
FA401EA.304

This machine is already running the latest firmware/BIOS currently
available for the FA401EA. Therefore, at least on this unit, the issue
is reproducible with the latest available ASUS firmware installed.

Running kernel:
7.3.0-rc2-fa401ea-rt721+

Kernel source tree HEAD:
1a3fdcb408 ASoC: rt721-sdca: Adjust latency control to fix no-sound issue

This includes the a20afec40ea1 fix.

The following patch was NOT present during this test:

ASoC: rt721-sdca: Update preset for all functions

Audio card:

amd-soundwire
ASUSTeKCOMPUTERINC.-TUFGamingA14FA401EA-1.0-FA401EA

SmartMic capture PCM:

card: amdsoundwire
device 4: SDW1-PIN5-CAPTURE-SmartMic
DAI: rt721-sdca-aif3-4

---

## DIAGNOSTIC MODULE

I built a temporary out-of-tree snd-soc-rt721-sdca module matching the
running kernel.

No DKMS installation was performed and no permanent module replacement was made.

The temporary module initially only did the following:

1. Added MBQ address 0x5f00030 to the readable and volatile register lists.

2. Added rt_sdca_index_read() calls inside:

   rt721_sdca_pde11_event()

   to read:

   NID:   0x5f
   index: 0x30

   at three points:

   * before requesting mic-path PS0
   * after requesting mic-path PS0
   * before requesting PS3

The existing PDE2A power-state request itself was left unchanged.

---

## BASELINE READ-ONLY TEST

Before capture I enabled:

rt721 FU1E Capture Switch = on,on,on,on

Capture command:

arecord -D hw:amdsoundwire,4
-f S16_LE
-r 48000
-c 2
-d 3
/tmp/rt721-mic-test.wav

The register values were:

RT721TEST mic 5f:30 before PS0: 0xffb7
RT721TEST mic 5f:30 after PS0:  0xffb7
RT721TEST mic 5f:30 before PS3: 0xffb7

Therefore, on my affected FA401EA:

0x5f:0x30 = 0xffb7

and requesting PDE2A PS0 does NOT change it.

I then analyzed the raw PCM samples.

Capture:

144000 frames
48000 Hz
stereo
S16_LE
3 seconds

Channel 0:

min=0
max=0
RMS=0.00
nonzero samples=0/144000
nonzero percentage=0.00%
distinct sample values=1

Channel 1:

min=0
max=0
RMS=0.00
nonzero samples=0/144000
nonzero percentage=0.00%
distinct sample values=1

So the SmartMic capture is exact digital zero on both channels.

---

## 0xFFB7 VS 0xFFF7

Jack mentioned that the default value according to the RT721 specification for:

NID 0x5f
index 0x30

is:

0xfff7

My hardware returns:

0xffb7

Difference:

0xfff7
0xffb7
------

0x0040

So BIT(6) is the only difference between the value observed on my unit
and 0xfff7.

---

## FIRST ATTEMPT TO FORCE BIT(6)

I then modified the temporary module to set only BIT(6) using:

rt_sdca_index_update_bits(..., BIT(6), BIT(6))

rather than overwriting the entire register.

This should change:

0xffb7 -> 0xfff7

In the first attempt I performed this before requesting PS0.

That attempt failed safely:

RT721TEST mic 5f:30 before PS0: read failed: -16
RT721TEST force BIT6 failed: -16

-16 is EBUSY.

Since rt_sdca_index_update_bits() first reads the register and returns
immediately if the read fails, no register write occurred during this
first attempt.

After PS0 the register became readable and still contained:

0xffb7

There was also a runtime PM issue during this attempt:

runtime PM trying to activate child device sdw:0:1:025d:0721:01 but
parent (sdw-master-0-1) is not active

followed by:

Failed to resume device: -61
Slave 1 alert handling failed: -61

Because of this I did not consider the first attempt authoritative.

---

## FINAL CONTROLLED TEST

For the second attempt I moved the BIT(6) update until AFTER PDE2A had
been requested to PS0.

I also explicitly kept the complete relevant path runtime-active
during the experiment.

ACP PCI device:

/sys/bus/pci/devices/0000:64:00.5

SoundWire manager:

/sys/devices/pci0000:00/0000:00:08.1/0000:64:00.5/amd_sdw_manager.1

RT721 codec:

/sys/bus/soundwire/devices/sdw:0:1:025d:0721:01

For all three:

power/control = on
runtime_status = active

PipeWire, WirePlumber and alsa-state were stopped during the
experiment so nothing else held the ALSA devices.

RT721 status before capture:

Attached

The sequence inside rt721_sdca_pde11_event() was:

1. Read 0x5f:0x30
2. Request PDE2A PS0
3. Wait 10-20 ms
4. Read 0x5f:0x30 again
5. Set only BIT(6)
6. Read 0x5f:0x30 again to verify the write
7. Perform SmartMic capture
8. Read 0x5f:0x30 before PS3
9. Clear BIT(6) again
10. Read back the register to verify restoration
11. Request PS3

The resulting kernel log was:

RT721_BIT6_V2_BEGIN

RT721TEST mic 5f:30 before PS0: 0xffb7
RT721TEST mic 5f:30 after PS0: 0xffb7
RT721TEST mic 5f:30 after BIT6 set: 0xfff7
RT721TEST mic 5f:30 before PS3: 0xfff7
RT721TEST mic 5f:30 after BIT6 restore: 0xffb7

RT721_BIT6_V2_END

So the requested value was successfully written and verified by
hardware readback.

During the entire three-second capture:

0x5f:0x30 = 0xfff7

After capture, BIT(6) was cleared again and readback confirmed that
the original value was restored:

0x5f:0x30 = 0xffb7

---

## CAPTURE RESULT WITH 0x5F:0x30 = 0xFFF7

Capture command:

arecord -D hw:amdsoundwire,4
-f S16_LE
-r 48000
-c 2
-d 3
/tmp/rt721-mic-bit6-v2.wav

Capture:

144000 frames
48000 Hz
stereo
S16_LE

Channel 0:

min=0
max=0
RMS=0.00
nonzero samples=0/144000
nonzero percentage=0.00%
distinct sample values=1

Channel 1:

min=0
max=0
RMS=0.00
nonzero samples=0/144000
nonzero percentage=0.00%
distinct sample values=1

Therefore the microphone capture remained exact digital zero on both
channels even while 0x5f:0x30 was verified to be 0xfff7.

---

## SUMMARY

Firmware:

BIOS FA401EA.304
Latest currently available firmware for FA401EA
Issue still reproducible

Baseline:

0x5f:0x30 = 0xffb7
DMIC = exact digital zero

Normal PDE2A -> PS0:

0x5f:0x30 remains 0xffb7

Explicit BIT(6) set:

0x5f:0x30 becomes 0xfff7
hardware readback confirms 0xfff7

SmartMic capture while register is 0xfff7:

Channel 0 = exact digital zero
Channel 1 = exact digital zero

After capture:

BIT(6) cleared
0x5f:0x30 returns to 0xffb7

---

## CONCLUSION

On my affected FA401EA, explicitly setting NID 0x5f / index 0x30 to
the specification default value 0xfff7 is NOT sufficient to make the
microphones work.

The machine is already running BIOS FA401EA.304, which is the latest
firmware currently available for this model, and the issue is still
reproducible. Therefore there is no newer ASUS firmware currently
available for me to test against this behavior.

One interesting difference from the earlier reported register dump is
that my unit does not currently show 0x01c2 at 0x5f:0x30.

It shows:

0xffb7

both before and after the normal PDE2A PS0 request.

The only difference from the documented default value 0xfff7 is BIT(6).

However, setting BIT(6), verifying 0xfff7 by hardware readback, and
keeping that value for the entire capture still leaves both microphone
channels producing exact digital zeros.

This seems to suggest that some other part of the analog/vendor power
sequence is still required.

This could also explain why the community workaround which writes
several RT721 vendor analog power registers succeeds: that workaround
modifies considerably more than 0x5f:0x30, including codec-wide power
state at 0x5f:0x00 and other analog power registers.

I intentionally did NOT apply the complete vendor power sequence
during this test because I wanted to test Jack's 0x5f:0x30 question
independently and provide a clean result.

For reference, the internal speakers also remain completely silent on
this machine with a20afec40ea1 alone, as previously reported.

If you would like me to perform another targeted test, please specify
the exact register/value and at what state it should be read or
written, and I will try to reproduce it carefully.

Again, I am not experienced with Linux audio driver development and I
am relying on ChatGPT to help me understand the kernel code and
construct these diagnostic tests. I wanted to be transparent about
that.

Nevertheless, I have tried to keep the experiments minimal and
reversible and to verify register changes by hardware readback
wherever possible.

I hope these results help narrow down the issue.

Thanks,
Cristian


On Mon, Sep 14, 2026 at 9:13 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> On Mon, Sep 14, 2026 at 08:16:22PM +0800, Shengyu Qu wrote:
>
> > On my FA401EA this issue doesn't exist so I can't test. Maybe you can ask at
> > bugzilla so other users with this issue could test?
>
> > PS: maybe this is the issue for some old batches of RT721 chip? My device is
> > very new and this might be why I don't have this issue?
>
> Could some firmware update have done something that helps somehow?