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=-0.8 required=3.0 tests=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 4D1FDC54FCB for ; Thu, 23 Apr 2020 11:23:51 +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 C4C9D20728 for ; Thu, 23 Apr 2020 11:23:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Q5eSrXJp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4C9D20728 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 1D77016A5; Thu, 23 Apr 2020 13:22:59 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 1D77016A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1587641029; bh=xr17710v8efBUSO9WAXNRhAQfQTma4wJdn1DZl84G5g=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Q5eSrXJphlFjWdl7kLHu48wYlxA6vZI9RDaUXjZk1jNfUQ47oZbcbpIf/us4qBs3N wHVw4DYFic0BHY2leOSypcZVcMwtCX0BEmYHprbyhKcBzOueacgcq3k5qcBgAZsFLe uRzq7L4U+Uw8FOYGKUNsNe8bL4BPGGvNwXKl+Yo4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id C8FA6F801F5; Thu, 23 Apr 2020 13:22:08 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id B676DF80228; Thu, 23 Apr 2020 13:22:06 +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 C4307F801EC for ; Thu, 23 Apr 2020 13:22:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C4307F801EC X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2EAE9B0E2; Thu, 23 Apr 2020 11:22:02 +0000 (UTC) Date: Thu, 23 Apr 2020 13:22:02 +0200 Message-ID: From: Takashi Iwai To: Alexander Tsoy Subject: Re: [PATCH] ALSA: usb-audio: Apply async workaround for Scarlett 2i4 2nd gen In-Reply-To: References: <7190177d62f349eea7a5d1056924a63fc4270d43.camel@tsoy.me> <20200422185522.3347-1-grpintar@gmail.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=UTF-8 Content-Transfer-Encoding: 8bit Cc: Gregor Pintar , alsa-devel@alsa-project.org 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 Thu, 23 Apr 2020 09:22:36 +0200, Takashi Iwai wrote: > > On Thu, 23 Apr 2020 01:45:01 +0200, > Alexander Tsoy wrote: > > > > В Ср, 22/04/2020 в 22:28 +0200, Takashi Iwai пишет: > > > On Wed, 22 Apr 2020 21:26:23 +0200, > > > Alexander Tsoy wrote: > > > > В Ср, 22/04/2020 в 20:55 +0200, Gregor Pintar пишет: > > > > > On Wed, 22 Apr 2020 Alexander Tsoy wrote: > > > > > > В Вт, 21/04/2020 в 21:31 +0200, Takashi Iwai пишет: > > > > > > > I wonder, though, whether we can correct the rounding error > > > > > > > in > > > > > > > the > > > > > > > driver code, too. > > > > > > > > > > > > I'm not sure if it's possible with currently used Q16.16 > > > > > > arithmetic. > > > > > > > > > > Maybe calculate fixed correction shifts (like it would be > > > > > feedback)? > > > > > Something like leap year. > > > > > > > > > > In endpoint.c: > > > > > static inline unsigned get_usb_high_speed_rate(unsigned int rate) > > > > > { > > > > > return ((rate << 10) + 62) / 125; > > > > > } > > > > > I guess 62 tries to round it, but exact number is needed. So > > > > > exact > > > > > value for > > > > > 44100 should be 361267.2. For 48000 it is 360448. > > > > > If only we can deliver that 0.2 by shifting rate somehow? > > > > > > > > > > At least maybe it would be better to disable sample rates that do > > > > > not > > > > > divide > > > > > by 1000 on SYNC playback endpoints, if there are others sample > > > > > rates. > > > > > > > > > > But I'm not familar with the code or USB. > > > > > > > > I think instead of accumulating the fractional part of fs/fps in > > > > Q16.16 > > > > format we should accumulating remainder of division fs/fps. > > > > > > > > So for 44100 Hz and High Speed USB the calculations would be: > > > > > > > > fs = 44100 > > > > fps = 8000 > > > > rem = 44100 % 8000 = 4100 > > > > accum = 0 > > > > packet_size_min = 44100 / 8000 = 5 > > > > packet_size_max = 44100 + (8000 - 1) / 8000 = 6 > > > > > > > > > > > > 1. accum += rem = 4100 > > > > accum < fps => packet_size = packet_size_min = 5 > > > > > > > > 2. accum += rem = 8200 > > > > accum >= fps => { > > > > packet_size = packet_size_max = 6 > > > > accum -= fps = 200 > > > > } > > > > > > > > 3. accum += rem = 4300 > > > > accum < fps => packet_size = packet_size_min = 5 > > > > > > > > ... > > > > > > > > 80. accum += rem = 8000 > > > > accum >= fps => { > > > > packet_size = packet_size_max = 6 > > > > accum -= fps = 0 > > > > } > > > > ... > > > > > > Yeah, something like that is what I had in my mind. > > > It'd be greatly appreciated if someone can experiment it. > > > Unfortunately I have no proper USB-audio device now at hands... > > > > OK, here is a quick hacky patch, that seems to work for me: > > Awesome, thanks! > > The patch looks good enough. A minor fix would be reset sample_accum > at snd_usb_pcm_prepare(). It should be rather in snd_usb_endpoint_start(). > If someone can test more and it shows the positive result, I'd happy > take it. ... and on the second thought, I wonder whether the new method can be simply applied to all cases. Your code gives basically more accurate timing. If we are concerned about the possible regression by this, we can keep the old code and make it switchable via option or kconfig (if any). Takashi