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

[Cristian Timohi]

Hi Jack,

I have very good news: with the latest RT721 changes, audio is now
working correctly on my affected ASUS TUF Gaming A14 FA401EA.

I tested a new kernel based on:

Linux 7.3-rc7
24a19b953e

The RT721 stack used for the test was:

247b84c07b7
7325b35a12d
e2eb4873b901
ASoC: rt721-sdca: Adjust blindwrite flow to fix type detection issue

plus the vendor analog power-gates fix you previously sent me:

ASoC: rt721-sdca: power up the vendor analog gates

The original local commit for that patch was:

6577f2bf61309383a74864f1cf60d1ad80c21175

Because the RT721 code had changed, I ported the analog-gates patch
onto the newer RT721 code while preserving the same register values
and the FA401EA DMI matching.

The resulting kernel is:

7.3.0-rc7-fa401ea-jack-v2+

Results on the physical FA401EA:

- Internal speakers: WORKING
- Internal SoundWire microphones: WORKING
- Headphone jack detection: WORKING
- Headphone playback: WORKING
- Automatic jack insertion/removal events: WORKING
- Automatic switching between speakers and headphones: WORKING

The jack state is now correctly reported by ALSA.

With headphones inserted:

Headphone Jack = on
Headphone Switch = on

`alsactl monitor` also now reports events when inserting/removing the
headphone plug:

node hw:1, #11 (0,0,0,Headphone Jack,0) VALUE

Previously, on the same machine, there were no jack events at all and
`Headphone Jack` remained permanently off.

So on this affected FA401EA, the combination of the newer RT721
type-detection changes and the vendor analog power-gates fix appears
to fully resolve the Linux audio problem.

One important point is that the vendor analog-gates patch is still
required on this machine. Without it, the internal speakers are silent
and the internal SoundWire microphones do not work correctly. With it,
both work normally.

Could you please consider submitting the vendor analog power-gates fix
upstream as soon as possible and, if appropriate, make sure both this
fix and the RT721 type-detection changes reach mainline and the
relevant stable kernels?

On this FA401EA, both parts are needed for fully working audio:

- the analog-gates fix restores the internal speakers and internal microphones;
- the newer RT721 type-detection changes restore jack detection and
the 3.5 mm headphone path.

If the fixes are suitable for stable backporting, that would be
especially helpful, since affected FA401EA units otherwise still
require a custom kernel for fully working internal audio.

My goal is to return to the normal Fedora kernel and receive the fix
through standard kernel updates instead of maintaining a custom
kernel.

I am happy to test a final upstream version of the patch, a v2/v3
revision, or any stable-backport candidate on this laptop.

Thank you very much for helping debug this, everyone working on this
is very skilled. The machine now finally has working Linux audio.

Regards,
Cristian

On Thu, Oct 8, 2026 at 8:15 AM Jack Yu <jack.yu@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxx>
> > Sent: Sunday, October 4, 2026 2:45 AM
> > To: Jack Yu <jack.yu@xxxxxxxxxxx>; Cristian Timohi
> > <cristiantimohi@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>
> > Cc: wiagn233@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.
> >
> >
> >
> > 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?
>