On Wednesday 03 March 2010 21:07:21 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
what went wrong? (the pcm pointer w/dma pos never missed that greatly) Very unlikely that an IRQ just happened to come in between the register reads..with that frequency (> 1/50)
Just to make sure:
+void omap_mcbsp_buffstat(unsigned int id, unsigned int *xbuffstat,
unsigned int *rbuffstat)+{
- struct omap_mcbsp *mcbsp;
- if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
return;- if (!omap_mcbsp_check_valid_id(id)) {
printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);return;- }
- mcbsp = id_to_mcbsp_ptr(id);
- *xbuffstat = OMAP_MCBSP_READ(mcbsp->io_base, XBUFFSTAT);
- *rbuffstat = OMAP_MCBSP_READ(mcbsp->io_base, RBUFFSTAT);
+}
Yes, and your sysfs read function was actually calling the omap_mcbsp_buffstat, and than it prints out both of the buffstat in one line.
see, the above is not trusted. However, it's 100% trusted to read off the timestamps recorded at DMA IRQ callback. (and at that time the buffer has just been filled up.).
Well, in element mode it would be kind of safe to report the FIFO size as delay in all cases. But in threshold mode it is a bit different. It all depends how the threshold value has been configured: For example if the threshold is 400, than at startup you will have three consequent bursts filling the buffer to 1200, and leaving 80 locations still free in the buffer. But as the playback progresses and we have 400 free locations, than the DMA will be filling the FIFO to close to full.
if the threshold is 1024, than you will have one burst at startup, the buffer will have 1024 location filled and 256 free. But as the playback progresses and we have 1024 free locations, than the DMA will be filling the FIFO to close to full.
So yes, over time you will get pretty close estimation about the delay.
But I still think, that my proposal also gives pretty good estimation about the delay as well.
- Eero