[alsa-devel] GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248
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 ?
Dne 01. 07. 19 v 12:28 vanitha.channaiah@in.bosch.com napsal(a):
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.
- 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
Hello Jaroslav-san,
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.
I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size. But still I face the issue. Below output provided is for RCAR salvator which supports 2ch : Issue is with using 6 channels on hardware which supports 2ch.[same issue is seen on IMX which supports 8ch]
root@rcar-gen3:~# aplay -Dentertainment_main -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 8000 PERIOD_SIZE: NONE PERIOD_BYTES: (1056 1068) PERIODS: (3 4) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# aplay -Dentertainment_main --period-size=88 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 8000 PERIOD_SIZE: NONE PERIOD_BYTES: (1056 1068) PERIODS: (3 4) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# aplay -Dentertainment_main --period-size=89 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 8000 PERIOD_SIZE: NONE PERIOD_BYTES: (1056 1068) PERIODS: (3 4) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# aplay -Dentertainment_main --period-size=384 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 16000 PERIOD_SIZE: NONE PERIOD_BYTES: (2112 2124) PERIODS: (1 2) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# aplay -Dentertainment_main --period-size=352 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 16000 PERIOD_SIZE: NONE PERIOD_BYTES: (2112 2124) PERIODS: (1 2) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# aplay -Dentertainment_main --period-size=96 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 8000 PERIOD_SIZE: NONE PERIOD_BYTES: (1056 1068) PERIODS: (3 4) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# root@rcar-gen3:~# aplay -Dentertainment_main --period-size=192 -r11025 -c6 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD root@rcar-gen3:~# aplay -Dentertainment_main --period-size=96 -r11025 -c6 --buffer-size=192 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 8000 PERIOD_SIZE: NONE PERIOD_BYTES: (1056 1068) PERIODS: (1 2) BUFFER_TIME: (15963 15964) BUFFER_SIZE: 176 BUFFER_BYTES: 2112 TICK_TIME: 0 root@rcar-gen3:~# aplay -Dentertainment_main --period-size=384 -r11025 -c6 --buffer-size=768 -fS16_LE /dev/urandom -v Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 16000 PERIOD_SIZE: NONE PERIOD_BYTES: (2112 2124) PERIODS: (1 2) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0
Best regards, Vanitha Channaiah RBEI/ECF3
Tel. +91 80 6136-4436
-----Original Message----- From: Jaroslav Kysela perex@perex.cz Sent: Monday, July 1, 2019 6:03 PM To: Channaiah Vanitha (RBEI/ECF3) Vanitha.Channaiah@in.bosch.com Cc: Wischer Timo (ADITG/ESS) twischer@de.adit-jv.com; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248
Dne 01. 07. 19 v 12:28 mailto:vanitha.channaiah@in.bosch.com napsal(a):
This mail is regarding the fix at below: commit 37728639ae05de702825d96bd1d42e24ae772248 Author: Jaroslav Kysela mailto: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.
- 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 mailto:perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
Dne 03. 07. 19 v 14:17 Channaiah Vanitha (RBEI/ECF3) napsal(a):
Hello Jaroslav-san,
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.
I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size. But still I face the issue.
There is no exact 2ms period size for the rate 11025Hz, because it's float number 21.9780 (period size)... You may try values like 15,35,45,105 (anything which can match 11025 / PERIOD_SIZE without the remainder).
Jaroslav
participants (3)
-
Channaiah Vanitha (RBEI/ECF3) -
Jaroslav Kysela -
vanitha.channaiah＠in.bosch.com