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=-4.0 required=3.0 tests=BAYES_00, 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 54AE0C433E0 for ; Mon, 3 Aug 2020 16:56:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2DBEE20722 for ; Mon, 3 Aug 2020 16:56:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727015AbgHCQ4f (ORCPT ); Mon, 3 Aug 2020 12:56:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:40300 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726356AbgHCQ4f (ORCPT ); Mon, 3 Aug 2020 12:56:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 19217AB71; Mon, 3 Aug 2020 16:56:49 +0000 (UTC) Date: Mon, 03 Aug 2020 18:56:33 +0200 Message-ID: From: Takashi Iwai To: "Lu, Brent" Cc: Pierre-Louis Bossart , Guennadi Liakhovetski , "alsa-devel@alsa-project.org" , "Kuninori Morimoto" , Kai Vehmanen , "Rojewski, Cezary" , Jie Yang , "linux-kernel@vger.kernel.org" , Takashi Iwai , Liam Girdwood , "Sam McNally" , Mark Brown , "Ranjani Sridharan" , Daniel Stuart , Andy Shevchenko , Yu-Hsuan Hsu , Damian van Soelen , "yuhsuan@google.com" Subject: Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board In-Reply-To: References: <1596020585-11517-1-git-send-email-brent.lu@intel.com> <1596198365-10105-1-git-send-email-brent.lu@intel.com> <1596198365-10105-3-git-send-email-brent.lu@intel.com> <63bca214-3434-16c6-1b60-adf323aec554@linux.intel.com> 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 03 Aug 2020 18:45:29 +0200, Lu, Brent wrote: > > > > Hi Takashi, > > > > > > I've double checked with google. It's a must for Chromebooks due to > > > low latency use case. > > > > I wonder if there's a misunderstanding here? > > > > I believe Takashi's question was "is this a must to ONLY accept 240 samples > > for the period size", there was no pushback on the value itself. > > Are those boards broken with e.g. 960 samples? > > I've added google people to discuss directly. > > Hi Yuhsuan, > Would you explain why CRAS needs to use such short period size? Thanks. For avoid further misunderstanding: it's fine that CRAS *uses* such a short period. It's often required for achieving a short latency. However, the question is whether the driver can set *only* this value for making it working. IOW, if we don't have this constraint, what actually happens? If the driver gives the period size alignment, wouldn't CRAS choose 240? Takashi 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=-4.0 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 9F0ABC433DF for ; Mon, 3 Aug 2020 16:57:38 +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 2633520722 for ; Mon, 3 Aug 2020 16:57:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="P6bOMlHS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2633520722 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@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 A8945165E; Mon, 3 Aug 2020 18:56:47 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A8945165E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1596473857; bh=bfFq5fzNsmQ/2kpHQv16nK4V1Vqs/OQ7Kttmznrowd0=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=P6bOMlHSX+E/b/oPWcMtz13wR+LgWmOjYmOnvwM5yOKo80Xwvq+AXeT9m+YEX279J wOlk6X0VJjeDSE50D6lDLvWQgQZPorF+mJEcO9NWAyTusCkZufSsV2x2E2pP3wrlxf UZQg1yjCbFCgZDqE5knuOoZ0clSHPyqslV/BuTgk= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 3EE89F801F7; Mon, 3 Aug 2020 18:56:47 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 08543F80218; Mon, 3 Aug 2020 18:56:45 +0200 (CEST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 4C40BF80148 for ; Mon, 3 Aug 2020 18:56:34 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 4C40BF80148 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 19217AB71; Mon, 3 Aug 2020 16:56:49 +0000 (UTC) Date: Mon, 03 Aug 2020 18:56:33 +0200 Message-ID: From: Takashi Iwai To: "Lu, Brent" Subject: Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board In-Reply-To: References: <1596020585-11517-1-git-send-email-brent.lu@intel.com> <1596198365-10105-1-git-send-email-brent.lu@intel.com> <1596198365-10105-3-git-send-email-brent.lu@intel.com> <63bca214-3434-16c6-1b60-adf323aec554@linux.intel.com> 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: Guennadi Liakhovetski , "alsa-devel@alsa-project.org" , Kai Vehmanen , Kuninori Morimoto , "linux-kernel@vger.kernel.org" , "yuhsuan@google.com" , Takashi Iwai , Jie Yang , "Rojewski, Cezary" , Pierre-Louis Bossart , Liam Girdwood , Sam McNally , Mark Brown , Ranjani Sridharan , Daniel Stuart , Andy Shevchenko , Yu-Hsuan Hsu , Damian van Soelen 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 Mon, 03 Aug 2020 18:45:29 +0200, Lu, Brent wrote: > > > > Hi Takashi, > > > > > > I've double checked with google. It's a must for Chromebooks due to > > > low latency use case. > > > > I wonder if there's a misunderstanding here? > > > > I believe Takashi's question was "is this a must to ONLY accept 240 samples > > for the period size", there was no pushback on the value itself. > > Are those boards broken with e.g. 960 samples? > > I've added google people to discuss directly. > > Hi Yuhsuan, > Would you explain why CRAS needs to use such short period size? Thanks. For avoid further misunderstanding: it's fine that CRAS *uses* such a short period. It's often required for achieving a short latency. However, the question is whether the driver can set *only* this value for making it working. IOW, if we don't have this constraint, what actually happens? If the driver gives the period size alignment, wouldn't CRAS choose 240? Takashi