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

[Shengyu Qu <wiagn233@outlook.com>]

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?