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 Cristian,

Please don't use "Update preset for all functions" patch and still keep below patch

ASoC: rt721-sdca: Adjust latency control to fix no-sound issue
a20afec40ea1012659861e58374c1bcde2e18a43

after above steps, please dump the registers in below path during playback for both scenarios (speaker playback and headphone playback).

/sys/kernel/debug/regmap/<sdw addr>/registers
/sys/kernel/debug/regmap/<sdw MBQ-addr>/registers

Our FAE will also try to borrow devices from ASUS for further debugging.

Regards,
Jack

> -----Original Message-----
> From: Cristian Timohi <cristiantimohi@gmail.com>
> Sent: Wednesday, September 9, 2026 4:50 AM
> To: Jack Yu <jack.yu@realtek.com>
> Cc: 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;
> broonie@kernel.org; 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 Jack, Vijendar, all,
> 
> I tested both Realtek changes on the ASUS TUF Gaming A14 FA401EA (BIOS
> FA401EA.304).
> 
> For reference, audio works correctly under the factory-installed Windows 11 on
> this exact hardware: both the internal speakers and the
> 3.5 mm headphone output worked normally.
> 
> Test kernel:
> 
> current torvalds/linux master
> HEAD before the test: 5acbae5f7
> a20afec40ea1 cherry-picked
> local kernel: 7.3.0-rc2-fa401ea-rt721+
> Speaker fix: a20afec40ea1
> ================================
> 
> I first tested only:
> 
> ASoC: rt721-sdca: Adjust latency control to fix no-sound issue
> a20afec40ea1012659861e58374c1bcde2e18a43
> 
> Unfortunately, the internal speakers remain completely silent.
> 
> Direct ALSA playback on the SmartAmp PCM opens and runs normally:
> 
> speaker-test
> -D hw=amdsoundwire,DEV=2
> -c 2 -r 48000 -F S16_LE -t wav
> 
> There are no relevant RT721/SoundWire errors during playback, but there is no
> physical speaker output.
> 
> So a20afec40ea1 alone does not fix the speaker issue on this FA401EA unit.
> 
> "Update preset for all functions" patch
> ===========================================
> 
> I then applied Jack's:
> 
> 0001-ASoC-rt721-sdca-Update-preset-for-all-functions.patch
> 
> The patch applies cleanly on top of the above kernel.
> 
> With the patch unmodified, however, both playback paths fail to open with
> -ENODATA.
> 
> The RT721 remains attached:
> 
> sdw:0:1:025d:0721:01: Attached
> 
> but dmesg reports:
> 
> rt721-sdca sdw:0:1:025d:0721:01: Defer on undeferrable control: 5810100
> rt721-sdca sdw:0:1:025d:0721:01: Defer on undeferrable control: 5810100
> rt721-sdca sdw:0:1:025d:0721:01: ASoC error (-61): at
> snd_soc_pcm_component_pm_runtime_get() on sdw:0:1:025d:0721:01
> SDW1-PIN1-PLAYBACK-SmartAmp: ASoC error (-61): at __soc_pcm_open() on
> SDW1-PIN1-PLAYBACK-SmartAmp
> 
> The same runtime PM error also occurs for the SimpleJack playback path.
> 
> I traced this to the new write in rt721_sdca_jack_preset():
> 
> regmap_write(rt721->mbq_regmap, 0x5810100, 0x8021);
> 
> Experimental 0x5810100 -> 0x5810000 test
> ============================================
> 
> As a local experiment only, I changed that single write from:
> 
> regmap_write(rt721->mbq_regmap, 0x5810100, 0x8021);
> 
> to:
> 
> regmap_write(rt721->mbq_regmap, 0x5810000, 0x8021);
> 
> This restores normal PCM opening. The -61 / "Defer on undeferrable
> control: 5810100" messages disappear completely.
> 
> With this experimental change and the rest of the preset patch unchanged:
> 
> Internal speakers:
> 
> PCM opens and streams normally
> still completely silent
> 
> 3.5 mm headphones:
> 
> PCM opens and streams normally
> no intelligible audio is produced
> importantly, the previous buzzing noise is now gone
> 
> I also repeated the zero-PCM test:
> 
> timeout 10s bash -c '
> dd if=/dev/zero bs=192000 2>/dev/null |
> aplay -D hw=amdsoundwire,DEV=0
> -t raw -f S16_LE -r 48000 -c 2
> '
> 
> Previously this caused continuous buzzing while the playback path was active.
> 
> With the new preset patch plus the experimental 0x5810100 -> 0x5810000
> change, the headphone output is completely silent during zero-PCM
> playback: no buzz, but also no audio during normal playback.
> 
> Summary
> 
> a20afec40ea1 only:
> 
> speakers: silent
> headphone behavior unchanged
> 
> a20afec40ea1 + preset patch as provided:
> 
> RT721 stays Attached
> playback cannot open
> 0x5810100 causes -ENODATA / runtime PM failure
> 
> a20afec40ea1 + preset patch + experimental 0x5810100 -> 0x5810000:
> 
> PCM playback works again
> speakers remain silent
> headphones remain silent
> previous headphone buzz is eliminated
> no relevant RT721/SoundWire errors in dmesg
> 
> It therefore looks like the new preset does affect the analog headphone state
> on this hardware, since it removes the buzzing, but the codec still does not
> produce actual audio.
> 
> Please let me know if you would like me to test different register values or
> provide register/debug dumps from this state.
> 
> Bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=221958
> 
> Thanks,
> Cristian
> 
> On Fri, Sep 4, 2026 at 9:01 AM Jack Yu <jack.yu@realtek.com> wrote:
> >
> > Loop more
> >
> > Hi Mukunda,
> >
> > Regarding to speakers silent issue, a patch has been merged as below
> >
> > [1/1] ASoC: rt721-sdca: Adjust latency control to fix no-sound issue
> >       https://git.kernel.org/broonie/sound/c/a20afec40ea1
> >
> > and for headphone buzzes issue on playback, could you merge the attached
> patch and check if buzzes issue can be fixed?
> >
> > Regards,
> > Jack
> >
> > > -----Original Message-----
> > > From: Syed Saba Kareem <syed.sabakareem@amd.com>
> > > Sent: Thursday, September 3, 2026 4:41 PM
> > > To: Mukunda,Vijendar <vijendar.mukunda@amd.com>; Cristian Timohi
> > > <cristiantimohi@gmail.com>; Jack Yu <jack.yu@realtek.com>;
> > > Flove(HsinFu) <flove@realtek.com>
> > > Cc: 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;
> > > broonie@kernel.org; lgirdwood@gmail.com;
> > > linux-kernel@vger.kernel.org; Dommati, Sunil-kumar
> > > <Sunil-kumar.Dommati@amd.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.
> > >
> > >
> > >
> > > On 9/3/26 11:11, Mukunda,Vijendar wrote:
> > > >
> > > >
> > > > On 9/2/26 22:13, Cristian Timohi wrote:
> > > >> [You don't often get email from cristiantimohi@gmail.com. Learn
> > > >> why this is important at
> > > >> https://aka.ms/LearnAboutSenderIdentification ]
> > > >>
> > > >> ****
> > > >> Resending as plain text, as the previous message was rejected by
> > > >> the vger.kernel.org mailing list due to an HTML MIME part.
> > > >> Apologies to recipients who received the previous copy directly.
> > > >> ***
> > > >>
> > > >> Hello,
> > > >>
> > > >> I'm reporting an audio issue on an ASUS TUF Gaming A14 FA401EA
> > > >> (Ryzen AI MAX+ 392) using AMD ACP70 SoundWire and a Realtek RT721
> > > >> SDCA codec.
> > > >>
> > > >> I have reproduced the issue on a clean current vanilla 7.3-rc1
> > > >> kernel, so this does not appear to be Fedora-, PipeWire-, or
> > > >> desktop-specific.
> > > >>
> > > >> Current clean test environment
> > > >> ==============================
> > > >>
> > > >> Distribution:
> > > >>      Fedora 45
> > > >>
> > > >> Kernel:
> > > >>      7.3.0-0.rc1.260901.786262be.417.vanilla.fc45.x86_64
> > > >>
> > > >> snd_acp_sdw_legacy_mach quirk:
> > > >>      -1
> > > >>
> > > >> There are no remaining custom snd_acp_sdw_legacy_mach/modprobe
> > > >> overrides in the current reproduction environment.
> > > >>
> > > >> Hardware
> > > >> ========
> > > >>
> > > >> Laptop:
> > > >>      ASUS TUF Gaming A14 FA401EA
> > > >>
> > > >> DMI product:
> > > >>      TUF Gaming A14 FA401EA
> > > >>
> > > >> DMI board:
> > > >>      FA401EA
> > > >>
> > > >> BIOS:
> > > >>      FA401EA.304
> > > >>
> > > >> CPU/APU:
> > > >>      AMD Ryzen AI MAX+ 392
> > > >>
> > > >> Audio:
> > > >>      AMD ACP70 SoundWire
> > > >>      Realtek RT721 SDCA
> > > >>
> > > >> The SoundWire bus exposes one peripheral:
> > > >>
> > > >>      sdw:0:1:025d:0721:01: Attached
> > > >>
> > > >> I do not see TAS2783 devices enumerated on this unit.
> > > >>
> > > >> Known-good cases
> > > >> ================
> > > >>
> > > >> The laptop's built-in speakers worked correctly under the
> > > >> factory-installed Windows 11.
> > > >>
> > > >> USB audio also works correctly under Linux. I tested Corsair
> > > >> Virtuoso USB headphones and normal audio playback works.
> > > >>
> > > >> Therefore the issue appears specific to the internal AMD ACP70 ->
> > > >> SoundWire -> RT721 audio path.
> > > >>
> > > >> Actual behavior
> > > >> ===============
> > > >>
> > > >> Internal speakers:
> > > >>      Completely silent.
> > > >>
> > > >> 3.5 mm headphone jack:
> > > >>      No intelligible audio is produced.
> > > >>      When the analog audio path becomes active, the headphones
> > > produce
> > > >>      a continuous buzzing noise. The buzz stops when the
> playback/path
> > > >>      is deactivated.
> > > >>
> > > >> Opening the desktop sound control panel can also trigger the
> > > >> buzzing while the analog audio path is active.
> > > >>
> > > >> ALSA playback devices
> > > >> =====================
> > > >>
> > > >> The amd-soundwire card exposes:
> > > >>
> > > >>      device 0:
> > > >>      SDW1-PIN0-PLAYBACK-SimpleJack rt721-sdca-aif1-0
> > > >>
> > > >>      device 2:
> > > >>      SDW1-PIN1-PLAYBACK-SmartAmp rt721-sdca-aif2-2
> > > >>
> > > >> Direct ALSA reproduction
> > > >> ========================
> > > >>
> > > >> Internal speakers:
> > > >>
> > > >>      speaker-test -D hw:CARD=amdsoundwire,DEV=2 \
> > > >>          -c 2 -r 48000 -F S16_LE -t wav
> > > >>
> > > >> The PCM stream starts normally without an ALSA error, but there
> > > >> is no physical speaker output.
> > > >>
> > > >> Analog headphones:
> > > >>
> > > >>      aplay -D plughw:CARD=amdsoundwire,DEV=0 \
> > > >>          /usr/share/sounds/alsa/Front_Left.wav
> > > >>
> > > >> No speech is heard. The headphone output only buzzes while the
> > > >> audio path is active.
> > > >>
> > > >> Zero-PCM test
> > > >> =============
> > > >>
> > > >> I also sent only zero-valued PCM samples:
> > > >>
> > > >>      timeout 10s bash -c '
> > > >>      dd if=/dev/zero bs=192000 2>/dev/null |
> > > >>      aplay -D hw:CARD=amdsoundwire,DEV=0 \
> > > >>            -t raw -f S16_LE -r 48000 -c 2
> > > >>      '
> > > >>
> > > >> The headphone jack still buzzes while the zero-PCM stream is active.
> > > >>
> > > >> Therefore the buzz does not appear to represent corrupted
> > > >> application audio; merely activating playback is sufficient to produce it.
> > > >>
> > > >> Mixer / UCM
> > > >> ===========
> > > >>
> > > >> Speaker:
> > > >>
> > > >>      Speaker Switch = on
> > > >>      rt721 FU06 Playback Volume = 87,87
> > > >>
> > > >> Headphones:
> > > >>
> > > >>      Headphone Switch = on
> > > >>      rt721 FU05 Playback Volume = 87,87
> > > >>
> > > >> I also explicitly enabled the corresponding Speaker and
> > > >> Headphones UCM devices. This did not change the result.
> > > >>
> > > >> ASoC DAPM during speaker playback
> > > >> =================================
> > > >>
> > > >> I inspected debugfs while speaker-test on the SmartAmp PCM was
> > > >> actively running.
> > > >>
> > > >> All relevant widgets were ON:
> > > >>
> > > >>      Speaker: On
> > > >>      rt721 DP3 Speaker Playback: On
> > > >>          stream DP3 Speaker Playback active
> > > >>      rt721 DP3RX: On
> > > >>      rt721 FU 21: On
> > > >>      rt721 FU 23: On
> > > >>      rt721 PDE 41: On
> > > >>      rt721 SPK: On
> > > >>
> > > >> The DAPM graph therefore appears to activate the entire expected
> > > >> speaker path:
> > > >>
> > > >>      DP3 Speaker Playback
> > > >>        -> DP3RX
> > > >>        -> FU 21 / FU 23
> > > >>        -> SPK
> > > >>        -> Speaker
> > > >>
> > > >> but the physical speakers remain silent.
> > > >>
> > > >> Kernel messages
> > > >> ===============
> > > >>
> > > >> RT721 attaches successfully.
> > > >>
> > > >> I see:
> > > >>
> > > >>      rt721-sdca sdw:0:1:025d:0721:01:
> > > >>      Driver needs fixing: Unsorted reg_defaults, sorting the copy
> > > >>
> > > >> On an earlier 7.2.x boot I also observed:
> > > >>
> > > >>      soundwire sdw:0:1:025d:0721:01:
> > > >>      PARITY error detected before INT mask is enabled
> > > >>
> > > >> I did not observe additional SoundWire/RT721 errors when starting
> > > >> or stopping playback.
> > > >>
> > > >> Kernels tested
> > > >> ==============
> > > >>
> > > >> The same issue was reproduced on:
> > > >>
> > > >>      Fedora 44:
> > > >>      7.2.2-300.fc44.x86_64
> > > >>
> > > >>      Fedora 45:
> > > >>      7.2.2-300.fc45.x86_64
> > > >>
> > > >>      Vanilla mainline:
> > > >>      7.3.0-0.rc1.260901.786262be.417.vanilla.fc45.x86_64
> > > >>
> > > >>      CachyOS kernel:
> > > >>      7.2.2-cachyos1.fc45.x86_64
> > > >>
> > > >> The current reproduction is on the clean vanilla 7.3-rc1 kernel.
> > > >>
> > > >> Previous experiments
> > > >> ====================
> > > >>
> > > >> Before testing clean mainline, I also built a Fedora 7.2.2 kernel
> > > >> locally and experimentally changed the RT721 speaker endpoint in:
> > > >>
> > > >>      sound/soc/amd/acp/amd-acp70-acpi-match.c
> > > >>
> > > >> from:
> > > >>
> > > >>      .aggregated = 0
> > > >>      .group_id = 0
> > > >>
> > > >> to:
> > > >>
> > > >>      .aggregated = 1
> > > >>      .group_id = 1
> > > >>
> > > >> This did not change the behavior.
> > > >>
> > > >> I also tested that custom kernel with:
> > > >>
> > > >>      options snd_acp_sdw_legacy_mach quirk=32768
> > > >>
> > > >> The kernel reported:
> > > >>
> > > >>      amd_sdw amd_sdw: Overriding quirk 0x1 => 0x8000
> > > >>
> > > >> but there was still no speaker output.
> > > >>
> > > >> Those experimental overrides have been removed. The current
> > > >> vanilla
> > > >> 7.3-rc1 reproduction uses quirk=-1 and no custom modprobe options.
> > > >>
> > > >> Question
> > > >> ========
> > > >>
> > > >> Could this FA401EA variant require a different RT721-only
> > > >> topology,
> > > >> ACP70 configuration, SoundWire setup, or codec initialization quirk?
> > > >>
> > > >> The fact that all-zero PCM causes the analog headphone output to
> > > >> buzz while the stream is active may be particularly relevant.
> > > >>
> > > >> I'm happy to test patches or provide register/debug output.
> > > >>
> > > >> I can also provide full alsa-info, kernel journal, lspci output,
> > > >> SoundWire sysfs state, mixer state, and DAPM debugfs output.
> > > >
> > > > Could you please log a Bugzilla ticket adding ACPI dump, dmi
> > > > information and along with alsa info output?
> > > ++RTK Team
> > >
> > > Similar kind of issue reported in another mail thread, realtek is working on
> it.
> > >
> > > @jack could you please comment on it.
> > >
> > > >>
> > > >> Thank you.
> > > >> Cristian
> > > >