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