[alsa-devel] [PATCH 3/3] ASoC: omap-mcbsp: make minimum period size larger than FIFO

[Peter Ujfalusi]

On 03/09/2012 03:25 PM, Grazvydas Ignotas wrote:
> I would guess they are using something larger, at least larger write
> quantities with this kind of period, otherwise it would keep
> overflowing there too.

They are using PulseAudio as with Maemmo (the product software).

>> So I'm a bit reluctant to ack these (it is not an issue on other McBSP
>> ports, and on OMAP4, but OMAP3 McBSP2 is problematic IMHO).
> 
> Maybe we could use MCBSPLP_THRSH2_REG XTHRESHOLD to artificially limit
> MCBSP2 fifo depth?

It is not possible. The McBSP FIFO/sDMA implementation (in HW) does not
allow it, unfortunately.
We are using the Threshold settings in dma_op_mode == threshold:
echo threshold > /sys/devices/platform/omap/omap-mcbsp.2/dma_op_mode

It is good for achieving lover power consumption during audio activity.

>> Jarkko: What do you think?
>>
>> If this is a real issue in Pandora, could it be solved with adding
>> /etc/asound.conf to the filesystem, and limit the period size via that?
> 
> We are already doing that, however we encourage people to install
> their own distros on pandora, and now they have to drag whole ALSA
> configuration for things to work. IMHO device driver like this must be
> able to work without any special userspace configuration.

We have two issues here:
if you are using the element mode (dma_op_mode) you might want to have
bigger period size than the FIFO size. However if you are using the
threshold mode you will be fine with a period size between fifo_size/2,
and fifo_size.
In threshold mode we are sending the data to McBSP FIFO in bursts, and
the burst size is the same as the McBSP threshold config. The McBSP will
request new burst when there is free space for the next burst in the
FIFO. So we can fill the FIFO to 3/4 for example, and the next burst
will happen when the FIFO reaches 1/4 fill level.

You might want to try this as well to lover the period_size constraint.

But let's wait for Jarkko's take on this.

-- 
Péter