From: Alexander Monakov <amonakov@ispras.ru> To: Takashi Iwai <tiwai@suse.de> Cc: linux-kernel@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Hui Wang <hui.wang@canonical.com>, Kailang Yang <kailang@realtek.com>, Jeremy Szu <jeremy.szu@canonical.com>, Jian-Hong Pan <jhp@endlessos.org>, Chris Chiu <chris.chiu@canonical.com>, PeiSen Hou <pshou@realtek.com>, alsa-devel@alsa-project.org Subject: Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42 Date: Wed, 28 Jul 2021 23:03:45 +0300 (MSK) [thread overview] Message-ID: <alpine.LNX.2.20.13.2107282230090.20403@monopod.intra.ispras.ru> (raw) In-Reply-To: <s5h7dhabcck.wl-tiwai@suse.de> On Wed, 28 Jul 2021, Takashi Iwai wrote: > > 1) at high enough gain, recording the microphone is picking up what is > > being played via the headphones; maybe it's supposed to be like that, > > but it surprised me; > > Hrm, that doesn't sound right. Some internal loopback in the codec? > Dunno. It doesn't pick up the sound physically, right? How can I tell? If I don't have anything plugged into the jack, playback uses the built-in speakers. In that case there's no feedback. And if I plug in a headset or common headphones, then built-in speakers are automatically muted, and recording the mic can pick up the output signal. Is there a way to forcefully direct output to the jack instead of built-in speakers even when there isn't anything plugged in? I am sure it is not picking the sound over the air, but I'm considering it's picking it up electrically near the jack somehow. > > 2) there is a very noticeable "pop" when plugging the headset in/out, > > accompanied by > > > > pcieport 0000:00:08.1: PME: Spurious native interrupt! > > pcieport 0000:00:08.1: PME: Spurious native interrupt! > > > > in dmesg. I'd appreciate info and any help about this issue. > > The pop noise is often a thing with the codec and there are a bunch of > different workarounds found in the driver. But the spurious interrupt > is more worrisome. Is the PCI slot corresponding to the HD-audio > controller? No, it's actually the PCI bridge under which the HDA core resides: 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus 00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller Note that I have autosuspend enabled for PCI devices. If I disable PCI autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious interrupt. My understanding that the chip generates a power management event when it senses a jack plug/unplug event while suspended. Apparently something about the PME interrupt is not fully in order? > As of now, I'm inclined to take your patch as is, at least as a > first-aid workaround. Let's see whether we get a better development > soonish. *nod*, I will appreciate it! Thank you. Alexander
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Monakov <amonakov@ispras.ru> To: Takashi Iwai <tiwai@suse.de> Cc: Chris Chiu <chris.chiu@canonical.com>, Jian-Hong Pan <jhp@endlessos.org>, Kailang Yang <kailang@realtek.com>, alsa-devel@alsa-project.org, Jeremy Szu <jeremy.szu@canonical.com>, Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org, Hui Wang <hui.wang@canonical.com>, PeiSen Hou <pshou@realtek.com> Subject: Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42 Date: Wed, 28 Jul 2021 23:03:45 +0300 (MSK) [thread overview] Message-ID: <alpine.LNX.2.20.13.2107282230090.20403@monopod.intra.ispras.ru> (raw) In-Reply-To: <s5h7dhabcck.wl-tiwai@suse.de> On Wed, 28 Jul 2021, Takashi Iwai wrote: > > 1) at high enough gain, recording the microphone is picking up what is > > being played via the headphones; maybe it's supposed to be like that, > > but it surprised me; > > Hrm, that doesn't sound right. Some internal loopback in the codec? > Dunno. It doesn't pick up the sound physically, right? How can I tell? If I don't have anything plugged into the jack, playback uses the built-in speakers. In that case there's no feedback. And if I plug in a headset or common headphones, then built-in speakers are automatically muted, and recording the mic can pick up the output signal. Is there a way to forcefully direct output to the jack instead of built-in speakers even when there isn't anything plugged in? I am sure it is not picking the sound over the air, but I'm considering it's picking it up electrically near the jack somehow. > > 2) there is a very noticeable "pop" when plugging the headset in/out, > > accompanied by > > > > pcieport 0000:00:08.1: PME: Spurious native interrupt! > > pcieport 0000:00:08.1: PME: Spurious native interrupt! > > > > in dmesg. I'd appreciate info and any help about this issue. > > The pop noise is often a thing with the codec and there are a bunch of > different workarounds found in the driver. But the spurious interrupt > is more worrisome. Is the PCI slot corresponding to the HD-audio > controller? No, it's actually the PCI bridge under which the HDA core resides: 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus 00:08.1/03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller Note that I have autosuspend enabled for PCI devices. If I disable PCI autosuspend for the 03:00.6 HDA device, there's no "pop" and no spurious interrupt. My understanding that the chip generates a power management event when it senses a jack plug/unplug event while suspended. Apparently something about the PME interrupt is not fully in order? > As of now, I'm inclined to take your patch as is, at least as a > first-aid workaround. Let's see whether we get a better development > soonish. *nod*, I will appreciate it! Thank you. Alexander
next prev parent reply other threads:[~2021-07-28 20:03 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-21 17:01 [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42 Alexander Monakov 2021-07-21 17:01 ` Alexander Monakov 2021-07-28 17:02 ` Takashi Iwai 2021-07-28 17:02 ` Takashi Iwai 2021-07-28 20:03 ` Alexander Monakov [this message] 2021-07-28 20:03 ` Alexander Monakov 2021-08-03 11:47 ` Takashi Iwai 2021-08-03 11:47 ` Takashi Iwai 2021-07-31 22:37 ` Nikos Liolios 2021-08-01 7:00 ` Alexander Monakov 2021-08-01 7:39 ` Takashi Iwai 2021-08-01 11:01 ` Nikos Liolios
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LNX.2.20.13.2107282230090.20403@monopod.intra.ispras.ru \ --to=amonakov@ispras.ru \ --cc=alsa-devel@alsa-project.org \ --cc=chris.chiu@canonical.com \ --cc=hui.wang@canonical.com \ --cc=jeremy.szu@canonical.com \ --cc=jhp@endlessos.org \ --cc=kailang@realtek.com \ --cc=linux-kernel@vger.kernel.org \ --cc=perex@perex.cz \ --cc=pshou@realtek.com \ --cc=tiwai@suse.com \ --cc=tiwai@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.