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

[Grazvydas Ignotas]

On Fri, Mar 9, 2012 at 2:42 PM, Peter Ujfalusi <peter.ujfalusi at ti.com> wrote:
> On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
>> With a program operating in minimum sized periods, first write
>> will cause a transfer that will fill mcbsp FIFO quickly, and there
>> will be no more data to DMA before program manages to do another
>> write. As the core considers this as underflow condition, we may
>> get many underflows at the start.
>> Increase minimum period size by half to deal with this problem.
>
> Not entirely sure about the last two patch...
> The implications will be big for existing user space since we are going
> to limit the period size in this way (on OMAP3 McBSP2):
> 48K stereo: 20ms min
> 44.1K stereo: 21.768ms min
> 8K stereo: 120ms min
> 8K mono: 240ms min
>
> As I recall n900 (+ MeeGo) uses 5ms period sizes in call cases on McBSP2.

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.

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

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


-- 
Gražvydas