On Fri, Mar 9, 2012 at 2:42 PM, Peter Ujfalusi peter.ujfalusi@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.