[alsa-devel] Question about snd_pcm_limit_hw_rates() call timing

[Takashi Iwai]

On Tue, 21 Jan 2020 09:11:06 +0100,
Kuninori Morimoto wrote:
> 
> 
> Hi Takashi
> 
> Thank you for feedback
> 
> > Actually the question is whether we need snd_pcm_limit_hw_rates() call
> > or not.  The current code in soc_pcm_init_runtime_hw() assumes that
> > each cpu and codec dais already set the proper rate_min and rate_max,
> > and narrow the range accordingly.  So basically the call there is
> > superfluous.  OTOH, in dpcm_fe_dai_startup(), the call overrides the
> > existing rate_min/max setup as you mentioned, so it may be wrong.
> 
> OK, it is same as my understanding.
> I want to do (so far) is just cleanup.
> I will fixup/cleanup it.
> 
> I'm posting ALSA SoC cleanup patches to ML.
> This fixup/cleanup will be added to my ALSA-SoC-cleanup-patch-queue

Actually as Lars pointed out in another reply, the current code of
soc_pcm_init_runtime_hw() is correct.  It's a bit tricky but smartly
handling the cases: when rate_min/max are to be overridden by rates
bits, they are supposed to be zero, and min_not_zero() does the
trick.  Also, snd_pcm_rate_mask_intersect() sanitizes the bits when
CONTINUOUS or KNOT is set, so the spurious rate bits won't be
reflected in snd_pcm_limit_hw_rates(), too.

But still the dpcm_fe_dai_startup() needs to be fixed as you
mentioned.  Though, I guess we need to fix not there but rather other
places (e.g. dpcm_set_fe_runtime() itself).


thanks,

Takashi