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

[Shengyu Qu]

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@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?