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 9ADEBC7619A for ; Sat, 8 Apr 2023 06:00:15 +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 65D5C741; Sat, 8 Apr 2023 07:59:22 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 65D5C741 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1680933612; bh=sK0Adr50YjD7tV/ho+bhRXGDL288zx+jQAZSBXXQWh0=; h=Date:From:To:Subject:In-Reply-To:References:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=JCSQK0TLm8e+IXArwyYCYwrOZPX6sJYSDtHZlNVP3EvPSy9KvJ76wTrU3okDBwt8w mtbcZH8xwGZAKQtniPlB0jem16pBQMXQc4XuKP0sL3j5iBdrYcmQERc7NXjGp37iM9 mDMepOpHgLhl4zRoNXad9OGJwM3wpT2UXPxRn4+A= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 29B9DF8026A; Sat, 8 Apr 2023 07:58:59 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 825BAF8026A; Sat, 8 Apr 2023 07:56:14 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6E960F8015B for ; Sat, 8 Apr 2023 07:55:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6E960F8015B Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=tcTkU9b/; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=e/PeABfa Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0D1611F8C4; Sat, 8 Apr 2023 05:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1680933349; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yDIPfPkE07slYWW1rWoUcGWZl5xd8oyM6CImo3ZWDi8=; b=tcTkU9b/0lpaBT9XiTA24cNEQ5yUAztBHegNfH6y4hAmzUPqPfTwpUsgmpKD6B3tAW6b6X yQp/9dFgS/nUsbapIPsLolXB49hrfa9ZEwx0kSE005AHE5aBTTQVfPa5mXCkph/f5qNYGj 1VFsWluhXMIuFfVgJvVeM5pcOzm9XWk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1680933349; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yDIPfPkE07slYWW1rWoUcGWZl5xd8oyM6CImo3ZWDi8=; b=e/PeABfai5qBSyxXm65Ld1p85DTPCzOHZdtbRlv3HzwfwWogVvZkMcVVClXRDMdYqejesB pAtUlIICgLgbOvDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D425113596; Sat, 8 Apr 2023 05:55:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Qw3+MuQBMWTuTQAAMHmgww (envelope-from ); Sat, 08 Apr 2023 05:55:48 +0000 Date: Sat, 08 Apr 2023 07:55:48 +0200 Message-ID: <87lej2sysb.wl-tiwai@suse.de> From: Takashi Iwai To: Jaroslav Kysela Subject: Re: [PATCH 2/2] ALSA: pcm: auto-fill buffer with silence when draining playback In-Reply-To: <3d75c103-7e94-e6a1-7f3d-7f957c33cddc@perex.cz> References: <20230405201219.2197789-1-oswald.buddenhagen@gmx.de> <20230405201219.2197789-2-oswald.buddenhagen@gmx.de> <3d75c103-7e94-e6a1-7f3d-7f957c33cddc@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-ID-Hash: NIB7XW7UVLPDFPMPGLKCDXP72B2WM2JK X-Message-ID-Hash: NIB7XW7UVLPDFPMPGLKCDXP72B2WM2JK X-MailFrom: tiwai@suse.de 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 CC: Oswald Buddenhagen , alsa-devel@alsa-project.org 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 Sat, 08 Apr 2023 01:58:21 +0200, Jaroslav Kysela wrote: > > On 05. 04. 23 22:12, Oswald Buddenhagen wrote: > > Draining will always playback somewhat beyond the end of the filled > > buffer. This would produce artifacts if the user did not set up the > > auto-silencing machinery. This patch makes it work out of the box. > > > > Rather than figuring out the right threshold (which is one period plus > > the card-specific FIFO size plus some IRQ jitter), we use "top-up" mode. > > > > Signed-off-by: Oswald Buddenhagen > > I think that it was really bad decision to apply this patch without a > broader discussion. When we designed the API, we knew about described > problems and we decided to keep this up to applications. The silencing > may not help in all cases where the PCM samples ends with a high > volume. A volume ramping should be used and it's an application > job. Also, silencing touches the DMA buffer which may not be > desired. And lastly drivers can handle draining correctly (stop at the > exact position - see substream->ops->trigger with > SNDRV_PCM_TRIGGER_DRAIN argument). > > I would create a new API extension for this (new ioctl or sw_params > flag), but the default behaviour should be retained. > > I will try to review the first patch too, but my time is limited over Easter. OK, thanks. I'll drop the patch meanwhile. Applying the silencing blindly might be an overkill, indeed, although this could be seen as an easy solution. Let's see. Takashi