Dne 01. 07. 19 v 12:28 vanitha.channaiah@xxxxxxxxxxxx napsal(a):
>
> This mail is regarding the fix at below:
> commit 37728639ae05de702825d96bd1d42e24ae772248
> Author: Jaroslav Kysela <perex@xxxxxxxx>
> Date: Sat Feb 7 15:01:31 2004 +00
> The commit has following changes :
>
> ******************************* code *****************************************
> static int snd_pcm_rate_hw_refine_cchange(snd_pcm_t *pcm, snd_pcm_hw_params_t *params,
> snd_pcm_hw_params_t *sparams)
> {
>
> + buffer_size = snd_pcm_hw_param_get_interval(params, SND_PCM_HW_PARAM_BUFFER_SIZE);
> + /*
> + * this condition probably needs more work:
> + * in case when the buffer_size is known and we are looking
> + * for best period_size, we should prefer situation when
> + * (buffer_size / period_size) * period_size == buffer_size
> + */
> + if (snd_interval_single(buffer_size) && buffer_size->integer) {
> + snd_interval_t *period_size;
> + period_size = (snd_interval_t *)snd_pcm_hw_param_get_interval(params, SND_PCM_HW_PARAM_PERIOD_SIZE);
> + if (!snd_interval_checkempty(period_size) &&
> + period_size->openmin && period_size->openmax &&
> + period_size->min + 1 == period_size->max) {
> + if ((buffer_size->min / period_size->min) * period_size->min == buffer_size->min) {
> + snd_interval_set_value(period_size, period_size->min);
> + } else if ((buffer_size->max / period_size->max) * period_size->max == buffer_size->max) {
> + snd_interval_set_value(period_size, period_size->max);
> + }
> + }
> + }
> }
> ******************************* code ****************************************
>
> Update rate depending on period_size and period_time.
> Issue found in Hardware :
> a. RCAR salvator-xs which supports 2 channel.
> b. IMX which supports 8 channel.
>
> 1. Usecase which is PASSED without the mentioned commit and FAILED with the commit.
>
> For the usecase with below command : rate = 11025 channel = 6
>
> $aplay -Dentertainment_main -r11025 -c6 -fS16_LE /dev/urandom
>
>
> a. With the commit:
>
> In the calculation of RATE at Rule 7:
> RATE=11025
> dependent parameters are:
> PERIOD_SIZE=88 PERIOD_TIME=8000
>
> parameters min max open_min open_max interval
>
> PERIOD_SIZE 88 88 0 0 0
> PERIO_TIME 8000 8000 0 0 0
> RATE 11025 11000 0 0 1
>
>
> RATE values are calculated in snd_interval_refine()
> Return value: INVALID as rate_min > rate_max
>
> This is because, dependent parameter “period_size” is rounded to 88 in “rate plugin” in snd_pcm_rate_hw_refine_cchange()
>
> Since, the below condition gets satisfied(buffer_size = 352 aligned to period_size = 88), period_size gets rounded to 88.
> if ((buffer_size->min / period_size->min) * period_size->min == buffer_size->min) {
>
> This commit changes causing the issue to get rate_min > rate_max.
>
> The flow of code execution is as follows:
> - snd_pcm_hw_refine_slave()
> - Enters snd_pcm_rate_hw_refine_cchange(), rounding of period_size to 88.
> - snd_pcm_rate_hw_refine_cchange() exit.
> - snd_pcm_hw_refine_soft() is called, here exists params->rmask to evaluate for SAMPLE_BITS, FRAME_BITS, PERIOD_BYTES, BUFFER_BYTES
> - execution of RULES calculation.
> At RULE 7 rate calculation INVALID error is observed.
>
> b. Without the commit:
> In the case if period_size doesn’t get rounded off to 88, the usecase would get PASSED.
> Rate calculation goes fine with period_size open interval (88, 89)
>
> parameters min max open_min open_max interval
>
> PERIOD_SIZE 88 89 0 0 0
> PERIOD_TIME 8000 8000 0 0 0
> RATE 11025 11025 0 0 1
>
> Here, there is no issue of rate_min > rate_max.
> ****************************************************************************************************************************************************************
> Now, I just have one scenario where with/without commit, rate calculation goes fine.
> 2. Usecase which is PASSED with and without above commit.
>
> For the usecase with below command : rate =11025 channel=2
> $aplay -Dentertainment_main -r11025 -c2 -fS16_LE /dev/urandom
>
> a. Including the above commit code:
> Below is the calculation that goes:
>
> The flow of code execution is as follows:
> - snd_pcm_hw_refine_slave()
> - Enters snd_pcm_rate_hw_refine_cchange() , rounding of period_size to 88.
> - snd_pcm_rate_hw_refine_cchange() exit.
> - snd_pcm_hw_refine_soft() is called, here params->rmask is 0.
> - RULES calculation doesnt occur.
>
> b. Without the commit:
> In the case if period_size doesn’t get rounded off to 88.
> Rate calculation goes fine with period_size open interval (88, 89)
>
> Is there any dependency for the commit ? If yes, can you please suggest the corner case
> which fails without the commit ?
> Can we revert the changes ?
I think that it would be probably best to force the parameters for your
hardware (--period-size and --buffer-size arguments for aplay or the time
counterparts - --period-time and --buffer-time). The refining rules might not
select the perfect configuration in some cases.
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
