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 > Sent: Thursday, September 3, 2026 4:41 PM > To: Mukunda,Vijendar ; Cristian Timohi > ; Jack Yu ; Flove(HsinFu) > > Cc: venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder > Chiou ; vkoul@kernel.org; > yung-chuan.liao@linux.intel.com; pierre-louis.bossart@linux.dev; > broonie@kernel.org; lgirdwood@gmail.com; linux-kernel@vger.kernel.org; > Dommati, Sunil-kumar > 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 > >