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

[Takashi Iwai <tiwai@suse.de>]

On Thu, 05 Nov 2026 10:22: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 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.
> 
> Which directions have hw_params is tracked in a new setup_streams mask
> under hdsp->lock: hw_params sets the bit, and a new hw_free callback
> and close clear it. The other substream's runtime state cannot be used
> for this, because the PCM core only moves it to SETUP after the driver's
> hw_params has returned and dropped hdsp->lock. Two threads calling
> hw_params on the two directions at once could then both change the
> speed mode.
> 
> 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>

Applied to for-next branch now.  Thanks.


Takashi