Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 04 May 2023 08:15:09 +0200
Message-ID: <87ttwsmxle.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc:     Jaroslav Kysela <perex@perex.cz>,
        Jeff Chua <jeff.chua.linux@gmail.com>,
        lkml <linux-kernel@vger.kernel.org>,
        Bagas Sanjaya <bagasdotme@gmail.com>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: linux-6.4 alsa sound broken
In-Reply-To: <ZFK9ZSm34Z3hQPF4@ugly>
References: <CAAJw_ZsbTVd3Es373x_wTNDF7RknGhCD0r+NKUSwAO7HpLAkYA@mail.gmail.com>
        <ZE9ngFLRqLkN6faH@ugly>
        <87wn1pmm4d.wl-tiwai@suse.de>
        <7b80ef1e-23dd-c523-0663-4bf311c1823a@perex.cz>
        <ZFK9ZSm34Z3hQPF4@ugly>
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

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