At Wed, 13 Jul 2011 11:44:03 +0530, Jassi Brar wrote:
On Wed, Jul 13, 2011 at 11:24 AM, Takashi Iwai tiwai@suse.de wrote:
- .channels_min = 2,
- .channels_max = 2,
- .buffer_bytes_max = MAX_IDMA_BUFFER,
- .period_bytes_min = 128,
- .period_bytes_max = MAX_IDMA_PERIOD,
In this case, MAX_IDMA_BUFFER is 160k and MAX_IDMA_PERIOD is 128k, buffer is not twice of period. If you set like this, many of general ALSA applications return error on initial buffers.
I don't think so. Did you see any such problem ? In my opnion, ALSA will always use 2 periods of approx. MAX_IDMA_BUFFER/2 bytes
It's not guaranteed unless you set explicitly a hw_constraint, such as snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
The ALSA API itself allows a buffer size not aligned to a period size.
Sure it does and we do set the constraint in Samsung's normal DMA driver where periods_max is quite large.
OK, I just want to be sure.
An important part missing in Claude's quote is
.periods_min = 1,.periods_max = 2,When the periods_max is only 2, the calculations in ALSA mid-layer seem to always decide on using two equal size periods.
I didn't dig in the logic but wasn't able to get any application to configure something like {Period_size = 90% of Buffer_size} which is actually beneficial for Low-Power-Audio-Mode.
Even you don't set the integer constraint, right? Does it happen with aplay with -Dhw?
In the driver side, there is a define RULES_DEBUG in sound/core/pcm_native.c, which will enable debug prints of hw-refines. A similar flag is found in alsa-lib/src/pcm/pcm_params.c, too.
Takashi