On Mon, Jan 30, 2017 at 11:56:52PM +0100, Sergej Sawazki wrote:
> On Mon, 30 Jan 2017 09:22:59 +0000, Charles Keepax wrote:
> > On Sat, Jan 28, 2017 at 12:35:45AM +0100, Sergej Sawazki wrote:
> >> Do not apply rate constraints in the startup() callback. The machine driver
> >> can change the sysclk and hence the supported frame rates in its hw_params().
> >> This callback is unneeded since commit e369bd006fd6 ("ASoC: wm8741: Allow
> >> master clock switching").
>
> > This function should not be removed it is performing a useful
> > function. If a sysclk has already been configured by the machine
> > driver then we should inform user-space of the rates we can
> > support from that clock. Without this that information is not
> > available to user-space, so instead of user-space being able to
> > resample appropriately it would just error out from hw_params.
> >
> > Are you perhaps missing a call to clear the sysclk from your
> > machine driver? Usually a dai_set_sysclk call with a rate of
> > zero, also I find if it is a machine driver supporting multiple
> > rates you are best to use ignore_pmdown_time on the DAI link,
> > assuming the devices don't have long bring up times.
>
> After clearing the sysclk, the codec should 'pretend' to support all
> rates, right? (no sysclk -> no rate constrains)
>
Indeed yes, so a normal pattern would often be setting a sysclk
rate in set_bias_level(on the way up)/hw_params and clearing it in
set_bias_level(on the way down). That way whilst the device is
powered up it is fixed at a certain rate so as not to disrupt any
running audio but whilst powered down you are free to start it up
at any rate.
> After applying rate constraints using snd_pcm_hw_constraint_list(...),
> what would be a clean way to remove the constraints from the rates
> parameter?
>
I am not sure I fully follow here, normally one would close the
stream and open a new one at the new rate. Hence no need to clear
the constraits as its a new stream. Are you intending to keep the
stream open but reconfigure it for new rates?
Thanks,
Charles
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
