[alsa-devel] [RFC 3/4] OMAP3: McBSP: Add interface for transmit FIFO state query

Peter Ujfalusi peter.ujfalusi at nokia.com
Wed Mar 3 16:01:39 CET 2010


On Wednesday 03 March 2010 16:18:42 ext Jarkko Nikula wrote:
> On Wed, 3 Mar 2010 12:02:48 +0200
> 
> Peter Ujfalusi <peter.ujfalusi at nokia.com> wrote:
> > The command for test:
> > aplay -fdat -d 1 /dev/urandom
> 
> I recommend to use /dev/zero instead since urandom takes CPU time.
> 
> > [   96.290924] XBUFFSTAT: 0
> > [   96.293487] XBUFFSTAT: 0
> > [   96.296020] XBUFFSTAT: 0
> > [   96.299774] XBUFFSTAT: 1
> > 
> > So the buffer is kept full in element mode, as it is expected.
> 
> I was expecting to see more variations. IRCC, the DMA in OMAP is doing
> transfers over the memory bus using some small bursts but I'm not
> completely sure. I'm thinking if that could explain the Eero's and
> Liam's observations?

I kind of expecting similar result (this).
In element mode the threshold value is 0 (1 word).
So if one word is free in McBSP buffer, than it will assert the DMA request 
line, and the DMA will write one word to McBSP.
So in theory the buffer must be kept full in this mode, with quite minimal 
variation.
But I might be wrong on this...

> 
> > So according to XBUFSTAT we have played out 289 samples.
> > based on the time we actually played 288.528 samples.
> > 
> > I would say this is really close to what we would expect to have?
> 
> Sounds accurate enough.
> 
> > Note: I have used printk for these, which pretty much alters the behavior
> > a bit in timing wise...
> 
> BTW: There is OMAP3 port in LTTng.

Thanks, I'll look at that, since this printk is altering the behavior too much.

-- 
Péter


More information about the Alsa-devel mailing list