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

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

Hi Shengyu,

Could you try the rt721 patch that is merged recently as below

[1/1] ASoC: rt721-sdca: Adjust blindwrite flow to fix type detection issue
      https://git.kernel.org/broonie/sound/c/e2eb4873b901

Regards,
Jack

> -----Original Message-----
> From: Shengyu Qu <wiagn233@outlook.com>
> Sent: Sunday, October 4, 2026 2:45 AM
> To: Jack Yu <jack.yu@realtek.com>; Cristian Timohi
> <cristiantimohi@gmail.com>; Mark Brown <broonie@kernel.org>
> Cc: wiagn233@outlook.com; Syed Saba Kareem
> <syed.sabakareem@amd.com>; Mukunda,Vijendar
> <vijendar.mukunda@amd.com>; Flove(HsinFu) <flove@realtek.com>;
> venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder Chiou
> <oder_chiou@realtek.com>; vkoul@kernel.org;
> yung-chuan.liao@linux.intel.com; pierre-louis.bossart@linux.dev;
> lgirdwood@gmail.com; linux-kernel@vger.kernel.org; Dommati, Sunil-kumar
> <Sunil-kumar.Dommati@amd.com>; Fish690103 <fish690103@realtek.com>;
> Mike Lin (林曉能) <mikelin@realtek.com>
> 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.
> 
> 
> 
> Hello Jack,
> 
> Any updates?
> 
> Best regards,
> Shengyu
> 
> 在 2026/9/15 11:44, Jack Yu 写道:
> > Hi Cristian,
> >
> > Could you check if the attached patch fix the issue?
> > Thanks.
> >
> > Regards,
> > Jack
> >
> >> -----Original Message-----
> >> From: Cristian Timohi <cristiantimohi@gmail.com>
> >> Sent: Tuesday, September 15, 2026 2:52 AM
> >> To: Mark Brown <broonie@kernel.org>
> >> Cc: Shengyu Qu <wiagn233@outlook.com>; Jack Yu <jack.yu@realtek.com>;
> >> Syed Saba Kareem <syed.sabakareem@amd.com>; Mukunda,Vijendar
> >> <vijendar.mukunda@amd.com>; Flove(HsinFu) <flove@realtek.com>;
> >> venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder
> >> Chiou <oder_chiou@realtek.com>; vkoul@kernel.org;
> >> yung-chuan.liao@linux.intel.com; pierre-louis.bossart@linux.dev;
> >> lgirdwood@gmail.com; linux-kernel@vger.kernel.org; Dommati,
> >> Sunil-kumar <Sunil-kumar.Dommati@amd.com>; Fish690103
> >> <fish690103@realtek.com>; Mike Lin (林曉能) <mikelin@realtek.com>
> >> 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@kernel.org>
> 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?