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 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 1A5FBC4332D for ; Sun, 10 Jan 2021 10:25:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4A2423A04 for ; Sun, 10 Jan 2021 10:25:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726447AbhAJKZE (ORCPT ); Sun, 10 Jan 2021 05:25:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:41204 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726410AbhAJKZD (ORCPT ); Sun, 10 Jan 2021 05:25:03 -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 19B0DAC5B; Sun, 10 Jan 2021 10:24:22 +0000 (UTC) Date: Sun, 10 Jan 2021 11:24:22 +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: <20210110091536.b3bc5dce2ef9d6c94d3eb873@gmx.com> References: <20210108103513.336e6eb9ad323feff6758e20@gmx.com> <20210109092303.b9a2a2f678a5d1b19b7f27f3@gmx.com> <20210109194601.f94ca38b2b99ddeb15705993@gmx.com> <20210110091536.b3bc5dce2ef9d6c94d3eb873@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 Sun, 10 Jan 2021 08:15:36 +0100, Lauri Kasanen wrote: > > On Sat, 09 Jan 2021 21:54:12 +0100 > Takashi Iwai wrote: > > > When the start starts, it copies the full period size data, and moves > > nextpos to period size while keeping pos 0. And, at this moment, it's > > even possible that no enough data has been filled for the period > > size; this is practically a buffer underrun. > > Usually PCM core can catch the buffer underrun by comparing the > > current position reported by the pointer callback against the filled > > size, but in this case, PCM core can't know of it because the driver > > just tells the position 0. This is one problem. > > > > Then, at the first period IRQ, the next period is copied, then nextpos > > becomes 2*period_size. At this moment, pos = nextpos, hence it jumps > > from 0 to 2*periodsize out of sudden. It's quite confusing behavior > > for applications. That's the second problem. > > > > I guess that both problems could be avoided if n64audio_pointer() > > reports always nextpos instead of pos. > > At first there was no nextpos, and _pointer() always reported pos. This > didn't work, the core played through the audio at chipmunk speed. So > there must be more that I don't understand here. Try to set the periods_min=2 and the integer periods hw constraint at first, and change the pointer callback to return nextpos. Also, at the push function, set runtime->delay = period_size as well. > Let me describe the hw, perhaps a different approach would be better. > - the DMA unit requires 8-byte alignment and 8-divisible size (two > frames at the only supported format, s16be stereo) This restriction needs to be set up as another hw constraint as long as you use the period size as the transfer size. > - the DMA unit has errata if (start + len) & 0x3fff == 0x2000, this > must never happen Ditto. > - the audio IRQ is not a timer, it fires when the card's internal > buffers are empty and need immediate refill It's the current implementation, right? Takashi