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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 82B64C77B61 for ; Thu, 13 Apr 2023 15:00:34 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 9FF88F11; Thu, 13 Apr 2023 16:59:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 9FF88F11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1681398031; bh=PuhnKqVh2UaWJCJxNjWnQ+m0PcNkTJ+5eFHm0awq0rg=; h=Date:From:To:Subject:References:In-Reply-To:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From; b=mKd7jZLQVJUm0p6WnJsEVWkb3enBJ2fVzOzoXpwABtwENWUkIjQxlkOSvujNjoJbG loyYeHW+88LwzJjP1ZIPM8gB2/0hYoHle8y1LOJXocOhh2lVCXE9/lPRKfh5REcn02 prKWIrooO6lxYjea2oyLqGZxSvIfSRgs08AYf/oA= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 2F847F8032B; Thu, 13 Apr 2023 16:59:18 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 934E1F8032B; Thu, 13 Apr 2023 16:59:13 +0200 (CEST) Received: from bluemchen.kde.org (bluemchen.kde.org [209.51.188.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C763AF8023A for ; Thu, 13 Apr 2023 16:59:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C763AF8023A Received: from ugly.fritz.box (localhost [127.0.0.1]) by bluemchen.kde.org (Postfix) with ESMTP id 5ED7920391 for ; Thu, 13 Apr 2023 10:59:03 -0400 (EDT) Received: by ugly.fritz.box (masqmail 0.3.4, from userid 1000) id 1pmyPe-hg4-00 for ; Thu, 13 Apr 2023 16:59:02 +0200 Date: Thu, 13 Apr 2023 16:59:02 +0200 From: Oswald Buddenhagen To: ALSA development Subject: Re: [PATCH 2/2] ALSA: pcm: auto-fill buffer with silence when draining playback Message-ID: Mail-Followup-To: ALSA development References: <7b317956-deb1-0a75-0a34-f82d6a81cf90@perex.cz> <87ttxl7cxd.wl-tiwai@suse.de> <87wn2ho06z.wl-tiwai@suse.de> <54c16616-dee7-b50f-d612-82eef906d1df@perex.cz> <871qkoxrrl.wl-tiwai@suse.de> <87ile0vzxp.wl-tiwai@suse.de> <87edoovvdy.wl-tiwai@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87edoovvdy.wl-tiwai@suse.de> Message-ID-Hash: FA66S2ASX6PZPMXNZKZY532PJ7P6PRTB X-Message-ID-Hash: FA66S2ASX6PZPMXNZKZY532PJ7P6PRTB X-MailFrom: ossi@kde.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Apr 13, 2023 at 02:06:49PM +0200, Takashi Iwai wrote: >On Thu, 13 Apr 2023 13:10:34 +0200, Oswald Buddenhagen wrote: >> i don't think that's true. if an app wants to control things finely, >> it would just use start/stop and manage the timing itself. draining >> otoh is a convenient fire-and-forget operation. that makes it easy to >> miss the finer details, which is why i'm so insistent that it should >> just work out of the box. > >Sure, but that's still no excuse to ignore the possibility blindly. > it's not blindly. it's after considering it, and concluding that it's a hypothetical problem at best. we could of course do a survey of actually existing publicly accessible code, to quantify the trade-off between apps fixed and apps broken. i actually sort of tried that ... first thing is that i found lots of stackoverflow answers and similar, and *none* of them even mentioned the need to clear the rest of the buffer. i found a bunch of libs, and none of the apidocs mentioned it in the parts i read. i found one cross-platform how-to which did actually mention it. yay. code search was trickier, with rather predictable results: basically all hits for drain() were immediately followed by close(). i found some simple cases of write+drain, and none of them did any additional padding. this includes alsa's own pcm example. but never mind, we're in agreement about this case. most other code was some abstraction, so it would be impossible to asses the bigger picture quickly. that would be even more the case for apps that use mmap. so i won't even try to provide actual data. one thing to consider here is that most of the code are cross-platform abstractions. under such circumstances, it seems kinda inconceivable that the higher level code would make any assumptions about buffer space that has not been filled with fresh samples. >> and doing it all in user space is yet more code. for all i can >> tell, it's really just layers of complexity to solve a non-problem. > >I don't get it: we're talking about the sw_params call in alsa-lib's >drain function, and how can it be *so* complex...? > the "drain function" bit is critical here, because it kind of implies resetting it, potentially asynchronously. but if we add a specific bit to the kernel to enable it, then it can be actually set already when the device is set up, and the user space would be rather simple. however, that would overall be still a lot more code than doing it unconditionally, and fully in kernel. regards