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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9FCFC77B7C for ; Thu, 4 May 2023 06:15:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229806AbjEDGPR (ORCPT ); Thu, 4 May 2023 02:15:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbjEDGPM (ORCPT ); Thu, 4 May 2023 02:15:12 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CE291980 for ; Wed, 3 May 2023 23:15:11 -0700 (PDT) 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 BE1EE208FE; Thu, 4 May 2023 06:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1683180909; 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=d0sfME+PPZ5V5RFQCvfOfX+BHGbYKlu9VTktkJ7gxMU=; b=BXV8QdqyhL+5kaPtttVPSi8CPQYetVaPlbq4eJYMMaXbH+ITomk8BPJViddT5nyviPzmf9 EZFur6SewI/FIE6QjPb6t9ZI+vbnF5Y8P8t4EL14nGHFEI1I9X/eOg3kUVNu5/DFHljGuz dtjOjKG2/XufJARI5DrtQmXq1WKFRaQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1683180909; 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=d0sfME+PPZ5V5RFQCvfOfX+BHGbYKlu9VTktkJ7gxMU=; b=/fYfg4UAJeiaOrTtwcq5d0o7z64GBeEudmhkv8euCcn7QhTVJJFPYTxxiKfNHk7nXZTl7a S5j81fAFCrirplDA== 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 967EC139C3; Thu, 4 May 2023 06:15:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Nn1nI21NU2TvaQAAMHmgww (envelope-from ); Thu, 04 May 2023 06:15:09 +0000 Date: Thu, 04 May 2023 08:15:09 +0200 Message-ID: <87ttwsmxle.wl-tiwai@suse.de> From: Takashi Iwai To: Oswald Buddenhagen Cc: Jaroslav Kysela , Jeff Chua , lkml , Bagas Sanjaya , ALSA development Subject: Re: linux-6.4 alsa sound broken In-Reply-To: References: <87wn1pmm4d.wl-tiwai@suse.de> <7b80ef1e-23dd-c523-0663-4bf311c1823a@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 03 May 2023 22:00:37 +0200, Oswald Buddenhagen wrote: > > On Wed, May 03, 2023 at 09:32:02PM +0200, Jaroslav Kysela wrote: > > On 03. 05. 23 18:10, Takashi Iwai wrote: > >> The dmix uses the silence_size=boundary as a fill-all operation, and > >> it's a free-wheel mode, so supposedly something was overlooked in your > >> code refactoring. > >> > >> Could you check it and address quickly? I'd like to fix it before > >> 6.4-rc1 release, so if no fix comes up in a couple of days, I'll have > >> to revert the change for 6.4-rc1. > > > > I would revert this patch. > > > It seems that this "do silence right after the playback is finished" > > mechanism is not handled in the updated code (and I overlooked that, > > too): > > > no, there is nothing wrong with the code _per se_. > > what's happening is that the dmix plugin doesn't update the > application pointer, and somehow gets away with it. > > that means that it would have never worked with thresholded silencing > mode, either, but, well, it uses top-up mode. Well, the code made just a wrong interpretation for the behavior with silence_size == boundary. This mode is actually a kind of tailored operation for dmix. In the description of alsa-lib snd_pcm_sw_params_set_silence_size(), you can find it: /** * \brief Set silence size inside a software configuration container * \param pcm PCM handle * \param params Software configuration container * \param val Silence size in frames (0 for disabled) * \return 0 otherwise a negative error code * * A portion of playback buffer is overwritten with silence when playback * underrun is nearer than silence threshold (see * #snd_pcm_sw_params_set_silence_threshold) * * The special case is when silence size value is equal or greater than * boundary. The unused portion of the ring buffer (initial written samples * are untouched) is filled with silence at start. Later, only just processed * sample area is filled with silence. Note: silence_threshold must be set to zero. */ So, the "top-up" silencing happens only at start, but not after that. In the code path of hw_ptr update, it doesn't check the appl_ptr any longer, but fills the processed area by the hw_ptr update with silence. That's the intended behavior for use cases of free-wheel mode without appl_ptr updates like dmix. Takashi