This mail is regarding the fix at below: commit 37728639ae05de702825d96bd1d42e24ae772248 Author: Jaroslav Kysela perex@perex.cz 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 ?