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.
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.