Hi Cristian, Could you check if the attached patch fix the issue? Thanks. Regards, Jack > -----Original Message----- > From: Cristian Timohi > Sent: Tuesday, September 15, 2026 2:52 AM > To: Mark Brown > Cc: Shengyu Qu ; Jack Yu ; > Syed Saba Kareem ; Mukunda,Vijendar > ; Flove(HsinFu) ; > venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder Chiou > ; 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 > ; Fish690103 ; > Mike Lin (林曉能) > 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 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?