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

Grazvydas Ignotas notasas at gmail.com
Fri Mar 9 22:07:00 CET 2012

On Fri, Mar 9, 2012 at 3:42 PM, Peter Ujfalusi <peter.ujfalusi at ti.com> wrote:
> 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.

Maybe enable it by default then?

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

Threshold mode doesn't seem to help, I still need to go over FIFO
size. From what I can see in the code it's setting the threshold to
period size, so I still get underflow condition after first write, as
first write goes to FIFO, DMA shows that it has nothing left to send
after first write finishes.

I bet PulseAudio is setting start threshold to something way above
FIFO size, which makes it work here. However you can't expect that
from every program that uses ALSA directly..

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

That would work if I did first write larger than period (when it's
below FIFO size) or set large enough start_threshold.
However if you look at alsalib samples, they always write in period
size quantities, so it's not surprising other programs do that too
(alsalib samples work here though as they do set high start

> 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


More information about the Alsa-devel mailing list