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

[Takashi Iwai]

At Wed, 13 Jul 2011 11:44:03 +0530,
Jassi Brar 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.

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