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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 28606C433DF for ; Mon, 10 Aug 2020 17:38:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ED36220885 for ; Mon, 10 Aug 2020 17:38:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="CJ32tAiB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727944AbgHJRil (ORCPT ); Mon, 10 Aug 2020 13:38:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727857AbgHJRij (ORCPT ); Mon, 10 Aug 2020 13:38:39 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DFC7C061756 for ; Mon, 10 Aug 2020 10:38:39 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id k20so326405wmi.5 for ; Mon, 10 Aug 2020 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EcJDg2O7xIbOjM5eLQ8gCplwOfat/XZVzxZppSuBFXA=; b=CJ32tAiBMpba2lWqmucba2kWsAmrucVE+nHFEbLfe7F/yDIu8a5GsC+aKvXiXYYyjH p6tY4SvZEFynuVENJxRY4zfZMk55Q8+jalMCUt5LbX15hB2LNARaGtL//JDIXpveJBnq U97ZMz+k45sAX4uHdrKeocRzAh6Iaba1kKKm8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EcJDg2O7xIbOjM5eLQ8gCplwOfat/XZVzxZppSuBFXA=; b=WO/4VOJp9+t9GHX/yAEFXpSYiIotEJOBQAXXwynl4qFKF53hisQzFzrouuIs1yg7F/ RA6aWBXa4CQEnC0BGXgD/0qJ7OhxbxzwGth7A/ak2QPMVVsL3tuvSQhPq7qCrI5NJIMk 4J3lrKZDz1EhpkFaY6SwUC+7h47AyZJ0EhRROUsKNIeNt6gwRH8BgmN8+D45590kh2H1 sXKhkma6ahu7i6pUyy/H/TXpiR/wr8D4Esd/f/W+lWPXSlwh4z2LeUhLGRXVvgFeIGnb Hw+9bnHC/mNvEP4XBZwfbtoW7dLSj7JF7eLd95rLpu4GkXGfR5G0CM3YEocBOBql8ZNi ll9w== X-Gm-Message-State: AOAM533RSRJ3lAEogzxSOYQKKwWCTqYynmnPVAk8hndwlcE3GzyUhS6+ j/7K3HRvES05++VzCro5xk6l60mFupozfJwAcPdrAw== X-Google-Smtp-Source: ABdhPJxWy126EoPeXn68o0RtdQ9AM8iu0r0roUOi2/tEIALG8XKSfLdRwQWvkOSSkWppyvAfQ/KenjZMRMb5iSGO57w= X-Received: by 2002:a05:600c:2302:: with SMTP id 2mr325053wmo.151.1597081117897; Mon, 10 Aug 2020 10:38:37 -0700 (PDT) MIME-Version: 1.0 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> <6466847a-8aae-24f7-d727-36ba75e95f98@linux.intel.com> <3f3baf5e-f73d-9cd6-cbfb-36746071e126@linux.intel.com> In-Reply-To: <3f3baf5e-f73d-9cd6-cbfb-36746071e126@linux.intel.com> From: Yu-Hsuan Hsu Date: Tue, 11 Aug 2020 01:38:26 +0800 Message-ID: Subject: Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board To: Pierre-Louis Bossart Cc: "Lu, Brent" , Takashi Iwai , Guennadi Liakhovetski , "alsa-devel@alsa-project.org" , Kai Vehmanen , Kuninori Morimoto , "Rojewski, Cezary" , Takashi Iwai , Jie Yang , "linux-kernel@vger.kernel.org" , "yuhsuan@google.com" , Liam Girdwood , Sam McNally , Mark Brown , Ranjani Sridharan , Daniel Stuart , Andy Shevchenko , Damian van Soelen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pierre-Louis Bossart =E6=96=BC 2020=E5=B9=B48=E6=9C=8810=E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=8811:= 03=E5=AF=AB=E9=81=93=EF=BC=9A > > > > On 8/6/20 11:41 AM, Lu, Brent wrote: > >> > >> I don't get this. If the platform driver already stated 240 and 960 sa= mples why > >> would 432 be chosen? Doesn't this mean the constraint is not applied? > > > > Hi Pierre, > > > > Sorry for late reply. I used following constraints in V3 patch so any p= eriod which > > aligns 1ms would be accepted. > > > > + /* > > + * Make sure the period to be multiple of 1ms to align the > > + * design of firmware. Apply same rule to buffer size to make > > + * sure alsa could always find a value for period size > > + * regardless the buffer size given by user space. > > + */ > > + snd_pcm_hw_constraint_step(substream->runtime, 0, > > + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 48); > > + snd_pcm_hw_constraint_step(substream->runtime, 0, > > + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 48); > > 432 samples is 9ms, I don't have a clue why/how CRAS might ask for this > value. > > It'd be a bit odd to add constraints just for the purpose of letting > userspace select a sensible value. Sorry for the late reply. CRAS does not set the period size when using it. The default period size is 256, which consumes the samples quickly(about 49627 fps when the rate is 48000 fps) at the beginning of the playback. Since CRAS write samples with the fixed frequency, it triggers underruns immidiately. According to Brent, the DSP is using 240 period regardless the hw_param. If the period size is 256, DSP will read 256 samples each time but only consume 240 samples until the ring buffer of DSP is full. This behavior makes the samples in the ring buffer of kernel consumed quickly. (Not sure whether the explanation is correct. Need Brent to confirm it.) Unfortunately, we can not change the behavior of DSP. After some experiments, we found that the issue can be fixed if we set the period size to 240. With the same frequency as the DSP, the samples are consumed stably. Because everyone can trigger this issue when using the driver without setting the period size, we think it is a general issue that should be fixed in the kernel. Thanks, Yu-Hsuan 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,URIBL_BLOCKED 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 82132C433E0 for ; Mon, 10 Aug 2020 17:39:44 +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 031D020885 for ; Mon, 10 Aug 2020 17:39:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="a9ufVswg"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="CJ32tAiB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 031D020885 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 3ECBD15F9; Mon, 10 Aug 2020 19:38:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 3ECBD15F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1597081182; bh=yRdCKJP+WI2M34o9eT71YkcI0TK2EPbAInBAcPP4Hp8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=a9ufVswgbLAJyUajB9eVQ7u/MnF0yxAxqnxl86zWzUK2qcDDLtWjJ4CP2MuFxx1oW bY2jWeBGEyc40gX5WhXS3BQT7p2iUuZrL5fydF/CWfCeo1v3wTJ2KKzzi5PEv+ZKo2 m8thFmMYzTqLH5hKCFccNKtIfvlALApXmgr6JkmI= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id A2A3AF801DB; Mon, 10 Aug 2020 19:38:51 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id D06CCF8022B; Mon, 10 Aug 2020 19:38:49 +0200 (CEST) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 0E3ABF800BC for ; Mon, 10 Aug 2020 19:38:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0E3ABF800BC Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="CJ32tAiB" Received: by mail-wm1-x342.google.com with SMTP id c80so306351wme.0 for ; Mon, 10 Aug 2020 10:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EcJDg2O7xIbOjM5eLQ8gCplwOfat/XZVzxZppSuBFXA=; b=CJ32tAiBMpba2lWqmucba2kWsAmrucVE+nHFEbLfe7F/yDIu8a5GsC+aKvXiXYYyjH p6tY4SvZEFynuVENJxRY4zfZMk55Q8+jalMCUt5LbX15hB2LNARaGtL//JDIXpveJBnq U97ZMz+k45sAX4uHdrKeocRzAh6Iaba1kKKm8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EcJDg2O7xIbOjM5eLQ8gCplwOfat/XZVzxZppSuBFXA=; b=tIWgWIzBUWXRKOvch+e0TseESBwn4Lz0CpaIaetVEFEDB2xbzqPcWPrzFZ+zjLnxT9 JDost0Npn3pJB2lrEHj5xZlNjsI74IRqVLQoQxf6uLiMWb/xXrRswbHvzx2t72H02uAT 4UrCsqhdzp0vHS4jdWfpzRTFIMAVXjAIov7hqcGHW1FFyh5XfgqxiRYv8qtwZc/8LQxv hA6QaTbszKsHIY+1hdwOsrdbMFQ1rakPVdVlK5LAjgXfc/le9biW7VErWtIho9l/1/gt Qu7DOi7YECBRrtKcNykS8Q2w7O7xEgCMLcBb8saYI1cX2iKapoGGxFuqnetyW2zKkoZI eedQ== X-Gm-Message-State: AOAM532Lal5ZQ7AytHYTjWWn65aAGQafnxsvYbh8NiNqp8hlQbqh4enE jDWag6QPGcZ6FQgq1GCNXos9h0EeuDIokOR0Qr+KKw== X-Google-Smtp-Source: ABdhPJxWy126EoPeXn68o0RtdQ9AM8iu0r0roUOi2/tEIALG8XKSfLdRwQWvkOSSkWppyvAfQ/KenjZMRMb5iSGO57w= X-Received: by 2002:a05:600c:2302:: with SMTP id 2mr325053wmo.151.1597081117897; Mon, 10 Aug 2020 10:38:37 -0700 (PDT) MIME-Version: 1.0 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> <6466847a-8aae-24f7-d727-36ba75e95f98@linux.intel.com> <3f3baf5e-f73d-9cd6-cbfb-36746071e126@linux.intel.com> In-Reply-To: <3f3baf5e-f73d-9cd6-cbfb-36746071e126@linux.intel.com> From: Yu-Hsuan Hsu Date: Tue, 11 Aug 2020 01:38:26 +0800 Message-ID: Subject: Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board To: Pierre-Louis Bossart Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Guennadi Liakhovetski , "alsa-devel@alsa-project.org" , Andy Shevchenko , Kuninori Morimoto , Kai Vehmanen , Takashi Iwai , "linux-kernel@vger.kernel.org" , Jie Yang , "Rojewski, Cezary" , Takashi Iwai , Liam Girdwood , Sam McNally , Mark Brown , Ranjani Sridharan , Daniel Stuart , "yuhsuan@google.com" , "Lu, Brent" , 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" Pierre-Louis Bossart =E6=96=BC 2020=E5=B9=B48=E6=9C=8810=E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=8811:= 03=E5=AF=AB=E9=81=93=EF=BC=9A > > > > On 8/6/20 11:41 AM, Lu, Brent wrote: > >> > >> I don't get this. If the platform driver already stated 240 and 960 sa= mples why > >> would 432 be chosen? Doesn't this mean the constraint is not applied? > > > > Hi Pierre, > > > > Sorry for late reply. I used following constraints in V3 patch so any p= eriod which > > aligns 1ms would be accepted. > > > > + /* > > + * Make sure the period to be multiple of 1ms to align the > > + * design of firmware. Apply same rule to buffer size to make > > + * sure alsa could always find a value for period size > > + * regardless the buffer size given by user space. > > + */ > > + snd_pcm_hw_constraint_step(substream->runtime, 0, > > + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 48); > > + snd_pcm_hw_constraint_step(substream->runtime, 0, > > + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 48); > > 432 samples is 9ms, I don't have a clue why/how CRAS might ask for this > value. > > It'd be a bit odd to add constraints just for the purpose of letting > userspace select a sensible value. Sorry for the late reply. CRAS does not set the period size when using it. The default period size is 256, which consumes the samples quickly(about 49627 fps when the rate is 48000 fps) at the beginning of the playback. Since CRAS write samples with the fixed frequency, it triggers underruns immidiately. According to Brent, the DSP is using 240 period regardless the hw_param. If the period size is 256, DSP will read 256 samples each time but only consume 240 samples until the ring buffer of DSP is full. This behavior makes the samples in the ring buffer of kernel consumed quickly. (Not sure whether the explanation is correct. Need Brent to confirm it.) Unfortunately, we can not change the behavior of DSP. After some experiments, we found that the issue can be fixed if we set the period size to 240. With the same frequency as the DSP, the samples are consumed stably. Because everyone can trigger this issue when using the driver without setting the period size, we think it is a general issue that should be fixed in the kernel. Thanks, Yu-Hsuan