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

[Jassi Brar]

On Wed, Jul 13, 2011 at 11:44 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> 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.
I meant any standard application without modifying it... like aplay,
mplayer, madplay etc.