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, 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 B483FC433E0 for ; Wed, 13 Jan 2021 12:39:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5793323382 for ; Wed, 13 Jan 2021 12:39:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725801AbhAMMjB (ORCPT ); Wed, 13 Jan 2021 07:39:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:56028 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbhAMMjB (ORCPT ); Wed, 13 Jan 2021 07:39:01 -0500 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 ECC90ADA2; Wed, 13 Jan 2021 12:38:19 +0000 (UTC) Date: Wed, 13 Jan 2021 13:38:19 +0100 Message-ID: From: Takashi Iwai To: Lauri Kasanen Cc: linux-mips@vger.kernel.org, tsbogend@alpha.franken.de, perex@perex.cz Subject: Re: [PATCH 5/6 v2] sound: Add n64 driver In-Reply-To: <20210113141453.1800fdc028fffcd232bb12e8@gmx.com> References: <20210108103513.336e6eb9ad323feff6758e20@gmx.com> <20210109092303.b9a2a2f678a5d1b19b7f27f3@gmx.com> <20210109194601.f94ca38b2b99ddeb15705993@gmx.com> <20210110091536.b3bc5dce2ef9d6c94d3eb873@gmx.com> <20210110190332.8a818e931975f02b8f3d3881@gmx.com> <20210110194146.58cf1d6d64a7fbc6d5336210@gmx.com> <20210111114323.d522f6e30a705d0731b41b93@gmx.com> <20210111140222.bb15bb75657fbb8a5b6863dd@gmx.com> <20210113135716.b8cb71c94edb7c7605002068@gmx.com> <20210113141453.1800fdc028fffcd232bb12e8@gmx.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 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, 13 Jan 2021 13:14:53 +0100, Lauri Kasanen wrote: > > On Wed, 13 Jan 2021 13:04:50 +0100 > Takashi Iwai wrote: > > > On Wed, 13 Jan 2021 12:57:16 +0100, > > Lauri Kasanen wrote: > > > I figured it out. Turns out the hw registers were double-buffered in a > > > way that requires two periods' worth of buffers. The IRQ fires when one > > > buffer is finished and another is queued, not when everything is > > > finished as I first thought. > > > > > > There doesn't seem to be a way to request the PCM core to keep two > > > periods' distance instead of one? I will deploy memcpy then. > > > > We may return to the first approach, i.e. just use nextpos. But then > > snd_pcm_period_elapsed() has to be called right after the trigger > > callback without the IRQ, because the trigger START already queued the > > full period and the position advances. So the first period-elapsed > > has to be called from a work or such offload instead of IRQ. > > In anyway, it's a bit tricky, yeah. > > I don't think that would work? When I printed out where > __snd_pcm_lib_xfer wrote data, it only steered clear of the current > period (pointer up to next period size). It wrote in every other part > of the buffer. This means the currently playing period would be racy. By advancing the hwptr, it fetches the full data, and PCM core already checks whether the data has been filled. If not filled, it emits the buffer underrun error to the application. So it enforces the next period filled beforehand. > The other point is that memcpy doesn't have a downside now - it doesn't > crackle when properly double-buffered. It's simpler this way vs > workqueues/etc. I'm fine with the other workaround as long as it works effectively. It needs more description in the code, though :) Takashi