From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82F47C4338F for ; Wed, 28 Jul 2021 20:03:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 67B746054F for ; Wed, 28 Jul 2021 20:03:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231352AbhG1UDw (ORCPT ); Wed, 28 Jul 2021 16:03:52 -0400 Received: from mail.ispras.ru ([83.149.199.84]:35726 "EHLO mail.ispras.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231126AbhG1UDv (ORCPT ); Wed, 28 Jul 2021 16:03:51 -0400 Received: from monopod.intra.ispras.ru (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 6F2F340755F2; Wed, 28 Jul 2021 20:03:45 +0000 (UTC) Date: Wed, 28 Jul 2021 23:03:45 +0300 (MSK) From: Alexander Monakov To: Takashi Iwai cc: linux-kernel@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , Hui Wang , Kailang Yang , Jeremy Szu , Jian-Hong Pan , Chris Chiu , PeiSen Hou , alsa-devel@alsa-project.org Subject: Re: [PATCH] ALSA: hda/realtek: add mic quirk for Acer SF314-42 In-Reply-To: Message-ID: References: <20210721170141.24807-1-amonakov@ispras.ru> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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