Re: [PATCH] ALSA: hdsp: allow sample rate changes from hw_params

[Takashi Iwai <tiwai@suse.de>]

On Sun, 01 Nov 2026 16:18:50 +0100,
Rafael Gago via B4 Relay wrote:
> 
> From: Rafael Gago <rafael.gago@gmail.com>
> 
> hdsp_set_rate() refuses to switch between single, double and quad
> speed whenever capture_pid or playback_pid is set. Both are set in the
> PCM open callbacks, so the substream that asks for the new rate in
> hw_params always blocks itself:
> 
>   cannot change speed mode (capture PID = -1, playback PID = 4242)
> 
> As a result no application can move an HDSP from 48 kHz to 96 kHz (or
> to 192 kHz on the H9632) through the normal ALSA API. Rate changes
> within one speed mode work, and a speed mode change only works through
> the "Sample Clock Source" control while no PCM is open, which is what
> users have to script around today.
> 
> The restriction exists because a speed mode change moves the channels
> to other DMA buffer slots (hdsp->channel_map) and changes the channel
> count, which must not happen under a substream that was already set up
> with the old layout. The substream calling hw_params is about to be set
> up anyway, so it is not such a substream.
> 
> Pass the requesting substream to hdsp_set_rate() in place of the
> called_internally flag, and from hw_params only refuse the speed mode
> change if the other direction is open and past the OPEN state, that is,
> it has hw_params of its own. A substream of another process is still
> turned away by the existing check in snd_hdsp_hw_params(), and requests
> from the controls and from card initialization (substream == NULL) keep
> the old rule of no open substreams at all.
> 
> A duplex client therefore opens both directions, sets hw_params on the
> first one (which may change the speed mode) and then on the second one
> at the same rate. To change the speed mode later it has to hw_free or
> close the other direction first.
> 
> Tested on an HDSP 9632 (v7.0 based kernel, same hdsp.c as v7.0) with
> aplay/arecord -M on hw:DSP: one stream moves the clock between 44.1k,
> 48k, 88.2k, 96k and 192k in both directions; alsaloop runs duplex in one
> process at 48k/12ch, 96k/8ch and 192k/4ch; while another process plays
> at 96k, a capture at 96k works and one at 48k or 192k is still refused;
> the "Sample Clock Source" control is still refused while a stream is
> open. REAPER on raw ALSA now changes the project rate between speed
> modes without presetting the clock first. Also built with W=1 on
> current mainline without warnings.
> 
> Only the HDSP 9632 was available for testing; the Digiface, Multiface,
> RPM and 9652 were not. The change is not model specific: the speed
> mode switch itself is the same code the "Sample Clock Source" control
> already runs on every model, and it still only happens while no stream
> is transferring data. The per-model channel counts and channel maps
> come from the driver's existing tables.
> 
> A Claude AI coding assistant (Claude Code) read the driver, wrote this
> change, the changelog and the tests at the request of the submitter,
> who reviewed them.
> 
> Signed-off-by: Rafael Gago <rafael.gago@gmail.com>

The idea sounds fine and the code looks mostly OK.
But there could be a race as Sashiko suggested:
  https://sashiko.dev/#/patchset/20261101-hdsp-sound-v1-1-f39f185400b5%40gmail.com
Could you check it?


thanks,

Takashi