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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 63616C432BE for ; Thu, 26 Aug 2021 06:09:24 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E2C7610A1 for ; Thu, 26 Aug 2021 06:09:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6E2C7610A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 160E7166F; Thu, 26 Aug 2021 08:08:32 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 160E7166F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1629958162; bh=EnkgpA4rp+5W4c9Ac4sdRC0Be1fVvF12IMKPLIB/Fb0=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mUZ+KczbmMuYir10aPauw1nEZGHpu6pcA7m7TpC5Rrg9y7MPSWut9fkVES57jYihP PWCVnM/QUtJ6G+WRUU6pFW15cLKGjAOdqhsjsXmGuxCtUwVwy9Mc6Q7D4Y3RrYR6sG F6amgZgHW3Kd1srpCSS5eq41tH4TAJihhZYdzLnI= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 9225BF801D8; Thu, 26 Aug 2021 08:08:31 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 39130F80224; Thu, 26 Aug 2021 08:08:30 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C942AF800FD for ; Thu, 26 Aug 2021 08:08:21 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C942AF800FD Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="YwCcb8w0"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="G5hTYS9f" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 4E74420167; Thu, 26 Aug 2021 06:08:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1629958101; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CzEYt05rk/qVLIT59VeDbT371fqbaUY2F6MlkZ/3ANE=; b=YwCcb8w072xMQFoTqny5CzLk8Fo2BfnIw1YVasbDDWEGD0Ey6huRgKv+wLfvZyECV9tR84 5CH4WF8WZ1dgvWA6eIWOn9ez3vR0MwoeP8KP3375PCI1Nq001lw7XIwxiK5YvELZlAem2U xKkiCfVVeyxeHiDjtsgYphxLn4Qbyo4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1629958101; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CzEYt05rk/qVLIT59VeDbT371fqbaUY2F6MlkZ/3ANE=; b=G5hTYS9fLSDyViPxRX162OVuOFCsOFRzia/+mvejuK0aF1VFw23VAMRiVtEhwMk3SCzR1c 6S/qFjUFFUWBT/CA== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 36457A3B8B; Thu, 26 Aug 2021 06:08:21 +0000 (UTC) Date: Thu, 26 Aug 2021 08:08:21 +0200 Message-ID: From: Takashi Iwai To: Jens Axboe Subject: Re: azx_get_pos_skl() induced system slowness In-Reply-To: References: <402d5952-3bf6-5c0d-5276-8367bfe1542a@kernel.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: alsa-devel@alsa-project.org, tiwai@suse.com, kai.vehmanen@linux.intel.com X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 25 Aug 2021 14:33:30 +0200, Jens Axboe wrote: > > On 8/25/21 12:14 AM, Takashi Iwai wrote: > > On Tue, 24 Aug 2021 19:38:08 +0200, > > Jens Axboe wrote: > >> > >> Hi, > >> > >> Got a new notebook recently, it's a Lenovo X1 Carbon 9th gen. Sound > >> works fine, but sometimes I get really stuttering playback from nestopia > >> and I finally decided to look into it. When this happens, > >> azx_get_pos_skl() is seemingly called a lot, at least it uses a ton of > >> CPU cycles. This comes and goes, sometimes 1 minute in between, > >> sometimes 2, and sometimes 30 seconds. > >> > >> If I comment out the udelay() in that function it does seems to be > >> noticeably better, though it's not a complete fix. I guess it just > >> reduces the pain of calling it so many times? > >> > >> This is running 5.14-rc7, but it's not a recent regression. > >> > >> Any clues as to what this might be? > > > > Are you using PulseAudio? Or pipewire? The former might cause lots > > of position update calls when the device doesn't give back the stable > > (or consistent) position report. > > I'm using the default (mint) which is pulseaudio. But after reading your > reply, I switched to pipewire - hopefully that'll work better! > > > The code there was borrowed from the ASoC Intel Skylake driver > > (sound/soc/intel/skylake/skl-pcm.c), and the same is also carried to > > the recent ASoC SOF HDA driver, too. > > As far as I understand from the comment, the udelay() itself could be > > reduced only for the case right after the interrupt wakeup. That is, > > a hackish patch like below might help. > > > > But, as far as I see with PulseAudio, it still results in a lot of > > register read -- so PA seems repeatedly reading the position. > > > > A better result (only from the CPU usage POV) could be gained on my > > machine by just switching to another position inquiry; namely, pass > > position_fix=1 option to snd-hda-intel module. But I checked this > > only for a short period, so am not sure about the long run. > > Let me know if you want to test the patch or using that option, for now > I just went with pipewire and will see if that works any better. Well, I'm interested in whether pipewire really works better in this regard, so please let me know your experience with PW, too ;) I'm going to check this issue on my machine, and will ask you if any test patch is ready. thanks, Takashi