>
> If the 1ms alignment is the condition, it can be better with a different
> hw_params constraint. We can use
> snd_pcm_hw_constraint_step() for such a purpose.
Will fix. Thanks.
Regards,
Brent
>
>
> thanks,
>
> Takashi
On Thu, 30 Jul 2020 17:27:58 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> >> Is this patch required if you've already constrained the period sizes for
> >> the
> >> platform driver in patch1?
> >
> > Yes or alsa will select 320 as default period size for it.
>
> ok, then that's a miss in your
> >>
> >> Yes or alsa will select 320 as default period size for it.
> >
> > ok, then that's a miss in your patch1. 320 samples is a multiple of
> > 1ms
>
> typo: is NOT
>
> > for 48kHz rates. I think it was valid only for the 16kHz VoIP paths
> > used in some versions of Android, but that we
On 7/30/20 10:27 AM, Pierre-Louis Bossart wrote:
Is this patch required if you've already constrained the period sizes
for the
platform driver in patch1?
Yes or alsa will select 320 as default period size for it.
ok, then that's a miss in your patch1. 320 samples is a multiple of 1ms
Is this patch required if you've already constrained the period sizes for the
platform driver in patch1?
Yes or alsa will select 320 as default period size for it.
ok, then that's a miss in your patch1. 320 samples is a multiple of 1ms
for 48kHz rates. I think it was valid only for the
>
> Is this patch required if you've already constrained the period sizes for the
> platform driver in patch1?
Yes or alsa will select 320 as default period size for it.
Regards,
Brent
On 7/29/20 6:03 AM, Brent Lu wrote:
From: Yu-Hsuan Hsu
The CRAS server does not set the period size in hw_param so ALSA will
calculate a value for period size which is based on the buffer size
and other parameters. The value may not always be aligned with Atom's
dsp design so a constraint
7 matches
Mail list logo
