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 E09C2C433DB for ; Mon, 11 Jan 2021 15:25:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8CDA522795 for ; Mon, 11 Jan 2021 15:25:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729111AbhAKPZu (ORCPT ); Mon, 11 Jan 2021 10:25:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:44668 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728048AbhAKPZu (ORCPT ); Mon, 11 Jan 2021 10:25:50 -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 52799B7BC; Mon, 11 Jan 2021 15:25:08 +0000 (UTC) Date: Mon, 11 Jan 2021 16:25:08 +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: <20210111140222.bb15bb75657fbb8a5b6863dd@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> 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 Mon, 11 Jan 2021 13:02:22 +0100, Lauri Kasanen wrote: > > On Mon, 11 Jan 2021 11:11:39 +0100 > Takashi Iwai wrote: > > > > This almost works, speed is correct, but the last part is played twice. > > > > Oh yes, at the last IRQ, the push should be avoided. > > I guess that the code order should be changed to the following way: > > > > 1. advance the position for a period size > > 2. call snd_pcm_period_elapsed() > > 3. check if the stream is still running > > 4. copy the next chunk and update nextpos > > This order gives correct pointer advancing etc, but now it's hitting a > new problem: the pcm core is reusing the buffer from under the audio > card. It's writing new data to the area that is currently being read by > DMA. Could you elaborate? I still don't get what's going on there. > I assume the core expects DMA to be instant, but in this card's case > it's ondemand, reading bytes as needed. No, PCM core doesn't expect it. The only expectation is that the data from the current pointer to the next period boundary will be transferred until the next period-elapsed call. > By restoring the memcpy buffer, I get good audio with this new order > (sans occasional crackling due to the memcpy taking too long). The overwriting problem has been already present in the original patch version as I already argued. The driver copies the full next period to be updated, but this is never guaranteed to have been filled by the application. Maybe this didn't surface obviously with the original version because it essentially gives one more period available on the buffer -- i.e. it might be a matter of number of periods. Takashi