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

[Jack Yu]

Hi Cristian,

Could you check if the attached patch fix the issue?
Thanks.

Regards,
Jack

> -----Original Message-----
> From: Cristian Timohi <cristiantimohi@xxxxxxxxx>
> Sent: Tuesday, September 15, 2026 2:52 AM
> To: Mark Brown <broonie@xxxxxxxxxx>
> Cc: Shengyu Qu <wiagn233@xxxxxxxxxxx>; Jack Yu <jack.yu@xxxxxxxxxxx>;
> Syed Saba Kareem <syed.sabakareem@xxxxxxx>; Mukunda,Vijendar
> <vijendar.mukunda@xxxxxxx>; Flove(HsinFu) <flove@xxxxxxxxxxx>;
> venkataprasad.potturu@xxxxxxx; linux-sound@xxxxxxxxxxxxxxx; Oder Chiou
> <oder_chiou@xxxxxxxxxxx>; vkoul@xxxxxxxxxx;
> yung-chuan.liao@xxxxxxxxxxxxxxx; pierre-louis.bossart@xxxxxxxxx;
> lgirdwood@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Dommati, Sunil-kumar
> <Sunil-kumar.Dommati@xxxxxxx>; Fish690103 <fish690103@xxxxxxxxxxx>;
> Mike Lin (林曉能) <mikelin@xxxxxxxxxxx>
> Subject: Re: [BUG] ASoC/AMD ACP70/RT721: ASUS TUF Gaming A14 FA401EA
> speakers silent and headphone jack buzzes on playback
> 
> 
> 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.
> 
> 
> 
> 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?

Attachment: 0001-ASoC-rt721-sdca-power-up-the-vendor-analog-gates.patch
Description: 0001-ASoC-rt721-sdca-power-up-the-vendor-analog-gates.patch