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@xxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
