[alsa-devel] [PATCH v5 4/4] ASoC: SAMSUNG: Add I2S0 internal dma driver

[Jassi Brar]

On Wed, Jul 13, 2011 at 11:24 AM, Takashi Iwai <tiwai at 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.