From: Takashi Iwai <tiwai@suse.de>
To: henrik.enquist@gmail.com
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Mark Brown <broonie@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 0/2] ALSA: aloop: Update the PCM Slave controls for a matching playback
Date: Wed, 21 Oct 2026 14:56:44 +0200 [thread overview]
Message-ID: <87v76vdxf7.wl-tiwai@suse.de> (raw)
In-Reply-To: <20261021-aloop-slave-controls-v1-0-62297727177f@gmail.com>
On Wed, 21 Oct 2026 09:46:44 +0200,
Henrik Enquist via B4 Relay wrote:
>
> Hi,
>
> One more aloop fix, after the notify mode one (ded1060369 "ALSA:
> aloop: Don't constrain playback params in notify mode"). I ran into
> this while working on a new CamillaDSP feature that uses notify mode.
> The "PCM Slave" controls are meant to report the playback's
> parameters, but often they don't. loopback_check_format() returns
> early when a capture is open and the parameters match, before it
> updates the controls. They then keep the module defaults, or the
> values of an earlier stream.
>
> This isn't specific to notify mode. Without notify, a playback that
> joins a running capture always has matching parameters, so the controls
> are never updated in that case. The early return has been there since
> the driver was added, hence the Fixes tag on the 2010 commit.
>
> Patch 1 skips only the capture stop when the parameters match, and
> always updates the controls. A value event is still sent only for a
> control whose value changes, so nothing new shows up except where a
> stale value gets corrected.
>
> Patch 2 adds a test for it to the aloop selftest. It doesn't need to go
> to stable, so it can wait for the next merge window if that's easier.
>
> Testing: for-linus at 443ed4edc2, arm64 VM, kernel with KASAN,
> lockdep, DEBUG_ATOMIC_SLEEP and DEBUG_LIST, comparing the patched
> driver with the unpatched one built from the same tree.
> - The selftest passes 5 of 5 patched. Unpatched, only the new test
> fails: the controls keep the earlier stream's values (96000 Hz,
> S32_LE, 4 channels, non-interleaved) and no value events arrive.
> - The reproducer in patch 1 reports 48000 unpatched and 44100 patched.
> - No KASAN, lockdep or other warnings in dmesg.
> Not tested: real hardware, other architectures.
>
> AI disclosure: as with the notify series, I used Claude Code (Claude
> Opus 5.5). It traced the bug through the driver and its history, wrote
> both patches and their changelogs, built the test kernels and ran the
> tests. I reviewed all of it.
>
> Henrik
>
> ---
> Henrik Enquist (2):
> ALSA: aloop: Update the PCM Slave controls for a matching playback
> selftests/alsa: Check the aloop PCM Slave controls for a matching playback
Applied both patches now. Thanks.
Takashi
prev parent reply other threads:[~2026-10-21 12:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 7:46 Henrik Enquist via B4 Relay
2026-10-21 7:46 ` [PATCH 1/2] " Henrik Enquist via B4 Relay
2026-10-21 7:46 ` [PATCH 2/2] selftests/alsa: Check the aloop " Henrik Enquist via B4 Relay
2026-10-21 12:56 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v76vdxf7.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=broonie@kernel.org \
--cc=henrik.enquist@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®