linux-kernel - Re: linux-6.4 alsa sound broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ttwsmxle.wl-tiwai@suse.de>
Date:   Thu, 04 May 2023 08:15:09 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Oswald Buddenhagen <oswald.buddenhagen@....de>
Cc:     Jaroslav Kysela <perex@...ex.cz>,
        Jeff Chua <jeff.chua.linux@...il.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        ALSA development <alsa-devel@...a-project.org>
Subject: Re: linux-6.4 alsa sound broken

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