[alsa-devel] GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248

[vanitha.channaiah at in.bosch.com]

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