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

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

[Cristian Timohi]

****
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.

Thank you.
Cristian

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

[Mukunda,Vijendar]

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?
>
> Thank you.
> Cristian

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

[Syed Saba Kareem]

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
>

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

[Jack Yu]

[-- Attachment #1: Type: text/plain, Size: 9237 bytes --]

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

[-- Attachment #2: 0001-ASoC-rt721-sdca-Update-preset-for-all-functions.patch --]
[-- Type: application/octet-stream, Size: 10972 bytes --]

From 6c021b1c8709f3497a1298d02ae72f3a1f4efe2f Mon Sep 17 00:00:00 2001
From: Jack Yu <jack.yu@realtek.com>
Date: Fri, 4 Sep 2026 10:41:56 +0800
Subject: [PATCH] ASoC: rt721-sdca: Update preset for all functions

Improve preset on all functions for better performance.

Signed-off-by: Jack Yu <jack.yu@realtek.com>
---
 sound/soc/codecs/rt721-sdca-sdw.c |   4 +
 sound/soc/codecs/rt721-sdca.c     | 174 ++++++++++++++++--------------
 2 files changed, 99 insertions(+), 79 deletions(-)

diff --git a/sound/soc/codecs/rt721-sdca-sdw.c b/sound/soc/codecs/rt721-sdca-sdw.c
index eae7d662efae..a3924522def1 100644
--- a/sound/soc/codecs/rt721-sdca-sdw.c
+++ b/sound/soc/codecs/rt721-sdca-sdw.c
@@ -74,10 +74,12 @@ static bool rt721_sdca_mbq_readable_register(struct device *dev, unsigned int re
 	case 0x200003c:
 	case 0x2000046:
 	case 0x5810000:
+	case 0x5810033:
 	case 0x5810036:
 	case 0x5810037:
 	case 0x5810038:
 	case 0x5810039:
+	case 0x5b10017:
 	case 0x5b10018:
 	case 0x5b10019:
 	case 0x5f00045:
@@ -149,10 +151,12 @@ static bool rt721_sdca_mbq_volatile_register(struct device *dev, unsigned int re
 	case 0x2000084:
 	case 0x2000086:
 	case 0x5810000:
+	case 0x5810033:
 	case 0x5810036:
 	case 0x5810037:
 	case 0x5810038:
 	case 0x5810039:
+	case 0x5b10017:
 	case 0x5b10018:
 	case 0x5b10019:
 		return true;
diff --git a/sound/soc/codecs/rt721-sdca.c b/sound/soc/codecs/rt721-sdca.c
index b1c3dc060c24..7a166594775c 100644
--- a/sound/soc/codecs/rt721-sdca.c
+++ b/sound/soc/codecs/rt721-sdca.c
@@ -173,7 +173,10 @@ static void rt721_sdca_dmic_preset(struct rt721_sdca_priv *rt721)
 		RT721_RC_CALIB_CTRL0, 0x0b00);
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
 		RT721_RC_CALIB_CTRL0, 0x0b40);
-	regmap_write(rt721->regmap, 0x2f5c, 0x25);
+	regmap_write(rt721->regmap,
+		SDW_SDCA_CTL(FUNC_NUM_MIC_ARRAY, RT721_SDCA_ENT_USER_FU10,
+			RT721_SDCA_CTL_SAMPLE_FREQ_INDEX, 0), 0x11);
+	regmap_write(rt721->regmap, 0x2f5c, 0x01);
 }
 
 static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
@@ -184,9 +187,6 @@ static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
 		RT721_VREF1_HV_CTRL1, 0xe000);
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
 		RT721_MISC_POWER_CTL31, 0x8007);
-	regmap_write(rt721->mbq_regmap, 0x5810000, 0x6420);
-	regmap_write(rt721->mbq_regmap, 0x5810000, 0x6421);
-	regmap_write(rt721->mbq_regmap, 0x5810000, 0xe421);
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
 		RT721_CH_FLOAT_CTL6, 0x5561);
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_REG,
@@ -211,81 +211,97 @@ static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
 
 static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
 {
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_MISC_POWER_CTL31, 0x8000);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
-		RT721_VREF1_HV_CTRL1, 0xe000);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_MISC_POWER_CTL31, 0x8007);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_GE_REL_CTRL1, 0x8011);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_UMP_HID_CTRL3, 0xcf00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_UMP_HID_CTRL4, 0x000f);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_UMP_HID_CTRL1, 0x1100);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_UMP_HID_CTRL5, 0x0c12);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_JD_CTRL,
-		RT721_JD_1PIN_GAT_CTRL2, 0xc002);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
-		RT721_RC_CALIB_CTRL0, 0x0b00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
-		RT721_RC_CALIB_CTRL0, 0x0b40);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_UAJ_TOP_TCON14, 0x3333);
-	regmap_write(rt721->mbq_regmap, 0x5810035, 0x0036);
-	regmap_write(rt721->mbq_regmap, 0x5810030, 0xee00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
-		RT721_HP_AMP_2CH_CAL1, 0x0140);
-	regmap_write(rt721->mbq_regmap, 0x5810000, 0x0021);
-	regmap_write(rt721->mbq_regmap, 0x5810000, 0x8021);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
-		RT721_HP_AMP_2CH_CAL18, 0x5522);
-	regmap_write(rt721->mbq_regmap, 0x5b10007, 0x2000);
-	regmap_write(rt721->mbq_regmap, 0x5B10017, 0x1b0f);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_CBJ_CTRL,
-		RT721_CBJ_A0_GAT_CTRL1, 0x2205);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
-		RT721_HP_AMP_2CH_CAL4, 0xa105);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_UAJ_TOP_TCON14, 0x3b33);
-	regmap_write(rt721->mbq_regmap, 0x310400, 0x3043);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_UAJ_TOP_TCON14, 0x3f33);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_UAJ_TOP_TCON13, 0x6048);
-	regmap_write(rt721->mbq_regmap, 0x310401, 0x3000);
-	regmap_write(rt721->mbq_regmap, 0x310402, 0x1b00);
-	regmap_write(rt721->mbq_regmap, 0x310300, 0x000f);
-	regmap_write(rt721->mbq_regmap, 0x310301, 0x3000);
-	regmap_write(rt721->mbq_regmap, 0x310302, 0x1b00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
-		RT721_UAJ_TOP_TCON17, 0x0008);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_DAC_CTRL,
-		RT721_DAC_2CH_CTRL3, 0x55ff);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_DAC_CTRL,
-		RT721_DAC_2CH_CTRL4, 0xcc00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
-		RT721_MBIAS_LV_CTRL2, 0x6677);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
-		RT721_VREF2_LV_CTRL1, 0x7600);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_ENT_FLOAT_CTL2, 0x1234);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_ENT_FLOAT_CTL3, 0x3512);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_ENT_FLOAT_CTL1, 0x4040);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_ENT_FLOAT_CTL4, 0x1201);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_BOOST_CTRL,
-		RT721_BST_4CH_TOP_GATING_CTRL1, 0x002a);
-	regmap_write(rt721->regmap, 0x2f58, 0x07);
-
-	regmap_write(rt721->regmap, 0x2f51, 0x00);
-	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
-		RT721_MISC_CTL, 0x0004);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_MISC_POWER_CTL31, 0x8000);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
+				RT721_VREF1_HV_CTRL1, 0xe000);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_MISC_POWER_CTL31, 0x8007);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				0x10, 0xffb7);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				0x20, 0xffb7);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				0x30, 0xffb7);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON13, 0x6048);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_GE_REL_CTRL1, 0x8011);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_UMP_HID_CTRL3, 0xcf00);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_UMP_HID_CTRL4, 0x000f);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_UMP_HID_CTRL1, 0x1100);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_UMP_HID_CTRL5, 0x0c12);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_JD_CTRL,
+				RT721_JD_1PIN_GAT_CTRL2, 0xc004);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
+				RT721_RC_CALIB_CTRL0, 0x0b00);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
+				RT721_RC_CALIB_CTRL0, 0x0b40);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON14, 0x333b);
+		regmap_write(rt721->mbq_regmap, 0x5810035, 0x8036);
+		regmap_write(rt721->mbq_regmap, 0x5810030, 0xee03);
+		regmap_write(rt721->mbq_regmap, 0x5810033, 0x6000);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
+				RT721_HP_AMP_2CH_CAL1, 0x4140);
+		regmap_write(rt721->mbq_regmap, 0x5810000, 0x0021);
+		regmap_write(rt721->mbq_regmap, 0x5810100, 0x8021);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
+				RT721_HP_AMP_2CH_CAL18, 0x5522);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
+				RT721_HP_AMP_2CH_CAL1, 0x4540);
+		regmap_write(rt721->mbq_regmap, 0x5b10017, 0x1b0f);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_CBJ_CTRL,
+				RT721_CBJ_A0_GAT_CTRL1, 0x2205);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON14, 0x3b3b);
+		regmap_write(rt721->mbq_regmap, 0x310400, 0x3043);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON14, 0x3f33);
+		regmap_write(rt721->mbq_regmap, 0x310401, 0x3000);
+		regmap_write(rt721->mbq_regmap, 0x310402, 0x1b00);
+		regmap_write(rt721->mbq_regmap, 0x310300, 0x000f);
+		regmap_write(rt721->mbq_regmap, 0x310301, 0x3000);
+		regmap_write(rt721->mbq_regmap, 0x310302, 0x1b00);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON17, 0x0008);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_DAC_CTRL,
+				RT721_DAC_2CH_CTRL3, 0x55ff);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_DAC_CTRL,
+				RT721_DAC_2CH_CTRL4, 0xcc00);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
+				RT721_MBIAS_LV_CTRL2, 0x6677);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_ANA_POW_PART,
+				RT721_VREF2_LV_CTRL1, 0x7600);
+		regmap_write(rt721->mbq_regmap, 0x910000, 0x00a1);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON13, 0x6048);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_ENT_FLOAT_CTL2, 0x1234);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_ENT_FLOAT_CTL3, 0x3512);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_ENT_FLOAT_CTL1, 0x4040);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
+				RT721_ENT_FLOAT_CTL4, 0x1201);
+		regmap_write(rt721->regmap, 0x2f58, 0x01);
+		regmap_write(rt721->regmap, 0x2f59, 0x01);
+		regmap_write(rt721->regmap, 0x2f51, 0x00);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+				RT721_UAJ_TOP_TCON13, 0x6040);
+		regmap_write(rt721->mbq_regmap, 0x910001, 0x3256);
+		regmap_write(rt721->mbq_regmap, 0x910002, 0x0000);
+		regmap_write(rt721->mbq_regmap, 0x910003, 0x0000);
+		regmap_write(rt721->mbq_regmap, 0x900004, 0x7778);
+		regmap_write(rt721->mbq_regmap, 0x910202, 0x02e4);
+		regmap_write(rt721->mbq_regmap, 0x800002, 0xcc04);
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_CAP_PORT_CTRL,
+				RT721_HP_AMP_2CH_CAL4, 0xa105);
+		rt_sdca_index_write(rt721->mbq_regmap, 0x0b, 0x01, 0x0000);
 }
 
 static void rt721_sdca_jack_init(struct rt721_sdca_priv *rt721)
-- 
2.54.0

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

[Cristian Timohi]

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

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

[Jack Yu]

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

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

[Cristian Timohi]

[-- Attachment #1: Type: text/plain, Size: 18415 bytes --]

Hi Jack,

Done.

I completely removed the "Update preset for all functions" patch and
rebuilt the RT721 module. The test kernel now contains only:

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

I attached the four requested register dumps:

* speaker-sdw.txt
* speaker-mbq.txt
* headphone-sdw.txt
* headphone-mbq.txt

For the speaker dumps, I used direct playback on:

hw:CARD=amdsoundwire,DEV=2

For the headphone dumps, headphones were connected and playback was running on:

plughw:CARD=amdsoundwire,DEV=0

Playback was kept running continuously until both the normal SDW and
MBQ register dumps had completed.

The two dumps for each scenario were captured immediately one after
the other while playback was still active.

Please let me know if you would like any additional register dumps or tests.

Thanks,
Cristian

On Wed, Sep 9, 2026 at 11:21 AM Jack Yu <jack.yu@realtek.com> wrote:
>
> 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
> > > > >

[-- Attachment #2: rt721-regdump.zip --]
[-- Type: application/zip, Size: 1924 bytes --]

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

[Shengyu Qu]

[-- Attachment #1.1: Type: text/plain, Size: 16467 bytes --]

Hi Jack,

Some community users found a way to fix this(though patch is from vibe
coding). Can you check why this really helps? I can't reproduce this on
my FA401EA so I can't give you more information for debugging.

Patches here: https://bugzilla.kernel.org/show_bug.cgi?id=221310#c75

Best regards,
Shengyu

在 2026/9/9 16:21, Jack Yu 写道:
> 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
>>>>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jack Yu]

Hi Shengyu / Cristian,

From the log on 
https://bugzilla.kernel.org/show_bug.cgi?id=221310#c76
                         stock driver (7.2.3, 7.3-rc2)   with the patch
  0x00 MISC_POWER_CTL0    not present in regmap cache     0xf69e
  0x20 amp path           not present in regmap cache     0xfff7  (idle, after playback)
  0x30 mic path           not present in regmap cache     0x01c2  (idle, no capture running)

those "with the patch" values are the default value in spec (0xf69e and 0xfff7), 
could you also check if set "nid 0x5f, index:0x30" to 0xfff7 can fix the issue (0xfff7 is default value for nid 0x5f, index:0x30)?
It's 0x01c2 when idle (referred from reported log), wonder if this is 0xfff7 when in mic-path normal case?

Regards,
Jack

> -----Original Message-----
> From: Shengyu Qu <wiagn233@outlook.com>
> Sent: Saturday, September 12, 2026 1:46 PM
> To: Jack Yu <jack.yu@realtek.com>; Cristian Timohi
> <cristiantimohi@gmail.com>
> Cc: wiagn233@outlook.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;
> 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
> 
> Hi Jack,
> 
> Some community users found a way to fix this(though patch is from vibe
> coding). Can you check why this really helps? I can't reproduce this on my
> FA401EA so I can't give you more information for debugging.
> 
> Patches here: https://bugzilla.kernel.org/show_bug.cgi?id=221310#c75
> 
> Best regards,
> Shengyu
> 
> 在 2026/9/9 16:21, Jack Yu 写道:
> > 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
> >>>>>

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

[Shengyu Qu]

[-- Attachment #1.1: Type: text/plain, Size: 19691 bytes --]

Hi Jack,

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?

Best regards,
Shengyu

在 2026/9/14 17:44, Jack Yu 写道:
> Hi Shengyu / Cristian,
> 
>  From the log on
> https://bugzilla.kernel.org/show_bug.cgi?id=221310#c76
>                           stock driver (7.2.3, 7.3-rc2)   with the patch
>    0x00 MISC_POWER_CTL0    not present in regmap cache     0xf69e
>    0x20 amp path           not present in regmap cache     0xfff7  (idle, after playback)
>    0x30 mic path           not present in regmap cache     0x01c2  (idle, no capture running)
> 
> those "with the patch" values are the default value in spec (0xf69e and 0xfff7),
> could you also check if set "nid 0x5f, index:0x30" to 0xfff7 can fix the issue (0xfff7 is default value for nid 0x5f, index:0x30)?
> It's 0x01c2 when idle (referred from reported log), wonder if this is 0xfff7 when in mic-path normal case?
> 
> Regards,
> Jack
> 
>> -----Original Message-----
>> From: Shengyu Qu <wiagn233@outlook.com>
>> Sent: Saturday, September 12, 2026 1:46 PM
>> To: Jack Yu <jack.yu@realtek.com>; Cristian Timohi
>> <cristiantimohi@gmail.com>
>> Cc: wiagn233@outlook.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;
>> 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
>>
>> Hi Jack,
>>
>> Some community users found a way to fix this(though patch is from vibe
>> coding). Can you check why this really helps? I can't reproduce this on my
>> FA401EA so I can't give you more information for debugging.
>>
>> Patches here: https://bugzilla.kernel.org/show_bug.cgi?id=221310#c75
>>
>> Best regards,
>> Shengyu
>>
>> 在 2026/9/9 16:21, Jack Yu 写道:
>>> 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
>>>>>>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Cristian Timohi]

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?

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

[Jack Yu]

[-- Attachment #1: Type: text/plain, Size: 11943 bytes --]

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?

[-- Attachment #2: 0001-ASoC-rt721-sdca-power-up-the-vendor-analog-gates.patch --]
[-- Type: application/octet-stream, Size: 8056 bytes --]

From 2575202d5e76e5b248f9129f5a4180950d755997 Mon Sep 17 00:00:00 2001
From: Jack Yu <jack.yu@realtek.com>
Date: Tue, 15 Sep 2026 11:36:49 +0800
Subject: [PATCH] ASoC: rt721-sdca: power up the vendor analog gates

On some boards firmware leaves the RT721's vendor analog power gates
off, which the SDCA power-domain requests do not touch,
so the codec is digitally configured but analog-dead.

Program these gates in the jack/amp/mic presets, gated on a DMI quirk
table (plus a vendor_power_seq module parameter) so other RT721 boards
keep the stock behaviour.

Signed-off-by: Jack Yu <jack.yu@realtek.com>
---
 sound/soc/codecs/rt721-sdca-sdw.c |  7 +++
 sound/soc/codecs/rt721-sdca.c     | 97 +++++++++++++++++++++++++++++++
 sound/soc/codecs/rt721-sdca.h     | 10 ++++
 3 files changed, 114 insertions(+)

diff --git a/sound/soc/codecs/rt721-sdca-sdw.c b/sound/soc/codecs/rt721-sdca-sdw.c
index eae7d662efae..bb7c77218fdf 100644
--- a/sound/soc/codecs/rt721-sdca-sdw.c
+++ b/sound/soc/codecs/rt721-sdca-sdw.c
@@ -63,6 +63,10 @@ static bool rt721_sdca_volatile_register(struct device *dev, unsigned int reg)
 static bool rt721_sdca_mbq_readable_register(struct device *dev, unsigned int reg)
 {
 	switch (reg) {
+	case 0x010000c:
+	case 0x010000e:
+	case 0x0100011:
+	case 0x0100013:
 	case 0x0900004 ... 0x0900009:
 	case 0x0a00005:
 	case 0x0c00005:
@@ -80,6 +84,9 @@ static bool rt721_sdca_mbq_readable_register(struct device *dev, unsigned int re
 	case 0x5810039:
 	case 0x5b10018:
 	case 0x5b10019:
+	case 0x5f00000:
+	case 0x5f00020:
+	case 0x5f00030:
 	case 0x5f00045:
 	case 0x5f00048:
 	case 0x6100000:
diff --git a/sound/soc/codecs/rt721-sdca.c b/sound/soc/codecs/rt721-sdca.c
index a9479d0e4941..da674c026101 100644
--- a/sound/soc/codecs/rt721-sdca.c
+++ b/sound/soc/codecs/rt721-sdca.c
@@ -9,6 +9,7 @@
 #include <linux/bitops.h>
 #include <sound/core.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/init.h>
 #include <sound/initval.h>
 #include <sound/jack.h>
@@ -140,6 +141,90 @@ static void rt721_sdca_btn_check_handler(struct work_struct *work)
 	pr_err_ratelimited("IO error in %s, ret %d\n", __func__, ret);
 }
 
+static int vendor_power_seq = -1;
+module_param(vendor_power_seq, int, 0444);
+MODULE_PARM_DESC(vendor_power_seq,
+	"RT721 vendor analog power sequence: -1 = DMI match, 0 = off, 1 = on");
+
+static const struct dmi_system_id rt721_sdca_quirk_table[] = {
+	{
+		/* ASUS TUF Gaming A14 FA401EA */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "FA401EA"),
+		},
+		.driver_data = (void *)RT721_SDCA_QUIRK_VENDOR_POWER_SEQ,
+	},
+	{
+		/* MSI Claw 8 EX AI+ */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "MS-1T91"),
+		},
+		.driver_data = (void *)RT721_SDCA_QUIRK_VENDOR_POWER_SEQ,
+	},
+	{}
+};
+
+struct rt721_sdca_power_step {
+	u8 nid;
+	u8 reg;
+	u16 mask;
+	u16 val;
+};
+
+static const struct rt721_sdca_power_step rt721_sdca_codec_power[] = {
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(15), BIT(15) },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(14), BIT(14) },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(13), BIT(13) },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(12), BIT(12) },
+	{ RT721_ANA_POW_PART,   RT721_ANA_POW_PART_11, BIT(15), BIT(15) },
+	{ RT721_ANA_POW_PART,   RT721_ANA_POW_PART_0C, BIT(15), BIT(15) },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(3),  BIT(3)  },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(10), BIT(10) },
+	{ RT721_ANA_POW_PART,   RT721_ANA_POW_PART_13, BIT(6),  BIT(6)  },
+	{ RT721_ANA_POW_PART,   RT721_ANA_POW_PART_0E, BIT(3),  BIT(3)  },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(2),  BIT(2)  },
+	{ RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(9),  BIT(9)  },
+};
+
+static void rt721_sdca_codec_analog_power(struct rt721_sdca_priv *rt721)
+{
+	size_t i;
+	int ret;
+
+	if (!(rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ))
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(rt721_sdca_codec_power); i++) {
+		ret = rt_sdca_index_update_bits(rt721->mbq_regmap,
+				rt721_sdca_codec_power[i].nid,
+				rt721_sdca_codec_power[i].reg,
+				rt721_sdca_codec_power[i].mask,
+				rt721_sdca_codec_power[i].val);
+		if (ret)
+			dev_warn(&rt721->slave->dev,
+				 "codec analog power step %zu failed: %d\n", i, ret);
+	}
+}
+
+/*
+ * Decide whether the vendor analog power sequence is needed. A module
+ * parameter forces it on or off; otherwise it is enabled only on boards in
+ * the DMI quirk table.
+ */
+static void rt721_sdca_detect_vendor_power(struct rt721_sdca_priv *rt721)
+{
+	if (vendor_power_seq == 0)
+		return;
+
+	if (vendor_power_seq > 0 || dmi_first_match(rt721_sdca_quirk_table)) {
+		rt721->quirks |= RT721_SDCA_QUIRK_VENDOR_POWER_SEQ;
+		dev_info(&rt721->slave->dev,
+			 "enabling vendor analog power sequence\n");
+	}
+}
+
 static void rt721_sdca_dmic_preset(struct rt721_sdca_priv *rt721)
 {
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
@@ -175,6 +260,10 @@ static void rt721_sdca_dmic_preset(struct rt721_sdca_priv *rt721)
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
 		RT721_RC_CALIB_CTRL0, 0x0b40);
 	regmap_write(rt721->regmap, 0x2f5c, 0x25);
+
+	if (rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ)
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+			RT721_MISC_POWER_CTL30, 0xfff7);
 }
 
 static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
@@ -208,6 +297,10 @@ static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
 		SDW_SDCA_CTL(FUNC_NUM_AMP, RT721_SDCA_ENT_FU55,
 			RT721_SDCA_CTL_FU_MUTE, CH_02), 0x00);
 	regmap_write(rt721->regmap, 0x2f5d, 0x1);
+
+	if (rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ)
+		rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+			RT721_MISC_POWER_CTL20, 0xfff7);
 }
 
 static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
@@ -287,6 +380,8 @@ static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
 	regmap_write(rt721->regmap, 0x2f51, 0x00);
 	rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
 		RT721_MISC_CTL, 0x0004);
+
+	rt721_sdca_codec_analog_power(rt721);
 }
 
 static void rt721_sdca_jack_init(struct rt721_sdca_priv *rt721)
@@ -1472,6 +1567,8 @@ int rt721_sdca_init(struct device *dev, struct regmap *regmap,
 	rt721->regmap = regmap;
 	rt721->mbq_regmap = mbq_regmap;
 
+	rt721_sdca_detect_vendor_power(rt721);
+
 	regcache_cache_only(rt721->regmap, true);
 	regcache_cache_only(rt721->mbq_regmap, true);
 
diff --git a/sound/soc/codecs/rt721-sdca.h b/sound/soc/codecs/rt721-sdca.h
index 24ce188562ba..d6879018d3b3 100644
--- a/sound/soc/codecs/rt721-sdca.h
+++ b/sound/soc/codecs/rt721-sdca.h
@@ -21,6 +21,7 @@ struct  rt721_sdca_priv {
 	struct snd_soc_component *component;
 	struct sdw_slave *slave;
 	struct sdw_bus_params params;
+	unsigned long quirks;
 	bool hw_init;
 	bool first_hw_init;
 	struct mutex calibrate_mutex;
@@ -74,6 +75,10 @@ struct rt721_sdca_dmic_kctrl_priv {
 #define RT721_MBIAS_LV_CTRL2			0x07
 #define RT721_VREF1_HV_CTRL1			0x0a
 #define RT721_VREF2_LV_CTRL1			0x0b
+#define RT721_ANA_POW_PART_0C			0x0c
+#define RT721_ANA_POW_PART_0E			0x0e
+#define RT721_ANA_POW_PART_11			0x11
+#define RT721_ANA_POW_PART_13			0x13
 
 /* Index (NID:04h) */
 #define RT721_DAC_2CH_CTRL3			0x02
@@ -127,6 +132,8 @@ struct rt721_sdca_dmic_kctrl_priv {
 
 /* Index (NID:5fh) */
 #define RT721_MISC_POWER_CTL0			0x00
+#define RT721_MISC_POWER_CTL20			0x20
+#define RT721_MISC_POWER_CTL30			0x30
 #define RT721_MISC_POWER_CTL31			0x31
 #define RT721_UAJ_TOP_TCON13			0x44
 #define RT721_UAJ_TOP_TCON14			0x45
@@ -268,6 +275,9 @@ enum {
 	RT721_AIFS,
 };
 
+/* quirks */
+#define RT721_SDCA_QUIRK_VENDOR_POWER_SEQ	BIT(0)
+
 int rt721_sdca_io_init(struct device *dev, struct sdw_slave *slave);
 int rt721_sdca_init(struct device *dev, struct regmap *regmap,
 			struct regmap *mbq_regmap, struct sdw_slave *slave);
-- 
2.54.0

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

[Cristian Timohi]

[-- Attachment #1: Type: text/plain, Size: 15143 bytes --]

Hi Jack,


I tested the patch you sent on my affected ASUS TUF Gaming A14 FA401EA.
The result is very promising: the patch fixes both the internal
speakers and the internal SoundWire microphones.

Test kernel: 7.3.0-rc2-fa401ea-jack-v1+
with your patch:
ASoC: rt721-sdca: power up the vendor analog gates

Results:

Internal speakers: FIXED
Internal SoundWire microphones: FIXED
Headphone jack detection: still not working
Headphone playback: still not working

I verified the internal microphones in Audacity and they now record normally.

The remaining headphone issue appears to involve more than just
automatic switching.
With headphones physically inserted, wpctl status is identical to the
state with the headphones disconnected.

The ALSA jack controls also remain:
Headphone Jack = off
Headset Mic Jack = off

I ran: `sudo alsactl monitor`
and inserted/removed the headphone plug multiple times.
No events were generated at all.

I also tried forcing the headphone playback path manually.
The relevant mixer controls initially showed:
Headphone Switch = off
Speaker Switch = on

I forced:

amixer -c amdsoundwire cset numid=9 1
amixer -c amdsoundwire cset numid=13 0

which resulted in:

Headphone Switch = on
Speaker Switch = off

Then I explicitly sent audio to the PipeWire headphone sink:

pw-play --target 58 /usr/share/sounds/alsa/Front_Center.wav

and also tested another WAV file.

There was still no sound from the headphones.

Therefore, on this FA401EA the current patch successfully fixes the
analog power-up needed for the speakers and internal microphones, but
the headphone path still appears to have two remaining problems:

Headphone/headset jack insertion is not detected/reported.
The headphone playback path remains silent even when Headphone Switch
is manually forced on and audio is explicitly routed to the headphone
sink.

I have attached a dmesg log filtered for
RT721/SoundWire/jack/headphone-related messages after booting with
your patch.
The laptop is still running BIOS FA401EA.304, the latest available
firmware for this model.

Please let me know what registers or additional diagnostics you would
like me to capture for the headphone/jack path. I am happy to continue
testing patches or register dumps on this unit.

Thanks,
Cristian

On Tue, Sep 15, 2026 at 6:44 AM Jack Yu <jack.yu@realtek.com> wrote:
>
> 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?

[-- Attachment #2: rt721-jack-after-jack-patch.txt --]
[-- Type: text/plain, Size: 1412 bytes --]

[    0.000000] Linux version 7.3.0-rc2-fa401ea-jack-v1+ (chris@Chris-Laptop) (gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2), GNU ld version 2.47.20260726) #2 SMP PREEMPT_DYNAMIC Tue Sep 15 21:31:03 EEST 2026
[    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.3.0-rc2-fa401ea-jack-v1+ root=UUID=81a48559-edf6-4b0b-96cd-1cb39dbcb77a ro rootflags=subvol=root rhgb quiet
[    0.039910] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.3.0-rc2-fa401ea-jack-v1+ root=UUID=81a48559-edf6-4b0b-96cd-1cb39dbcb77a ro rootflags=subvol=root rhgb quiet
[    1.674003] usb usb1: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.674924] usb usb2: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.676681] usb usb3: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.679174] usb usb4: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.681472] usb usb5: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.682339] usb usb6: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.684206] usb usb7: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    1.684966] usb usb8: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd
[    8.206709] rt721-sdca sdw:0:1:025d:0721:01: enabling vendor analog power sequence
[    8.212385] input: amd-soundwire Headset Jack as /devices/pci0000:00/0000:00:08.1/0000:64:00.5/amd_sdw/sound/card1/input22