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

[Eero Nurkkala]

On Thu, 2010-03-04 at 09:09 +0100, Ujfalusi Peter (Nokia-D/Tampere)
wrote:
> Hello,
> 
> On Wednesday 03 March 2010 21:00:58 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
> > From: Ujfalusi Peter
> > 
> > > 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?
> > > 
> > > Note: I have used printk for these, which pretty much alters the behavior
> > > a bit in timing wise...
> > > 
> > > --
> > > Péter
> > 
> > There was something like this, reading XBUFFSTAT and RBUFFSTAT
> > (adjacently), and comparing the diff, it should be 145 +-1 in this case,
> > but that's not true:
> > 
> > (usespace app reading the values through a sysfs node):
> > 
> > 1: tx: 247, rx: 101, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 2: tx: 377, rx: 232, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 3: tx: 136, rx: 471, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 4: tx:  40, rx: 375, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 5: tx:  63, rx: 398, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 6: tx: 444, rx: 299, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 7: tx: 330, rx: 185, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 8: tx: 198, rx:  53, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 9: tx: 453, rx: 308, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 10: tx: 459, rx: 313, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 11: tx: 353, rx: 208, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 12: tx: 435, rx: 290, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 13: tx: 421, rx: 276, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 14: tx: 397, rx: 251, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 15: tx: 297, rx: 151, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 16: tx: 341, rx: 196, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 17: tx: 347, rx: 202, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 18: tx: 298, rx: 153, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 19: tx: 341, rx: 196, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 20: tx: 121, rx: 456, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 21: tx: 109, rx: 444, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 22: tx: 465, rx: 320, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 23: tx: 300, rx: 155, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 24: tx: 217, rx:  72, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 25: tx: 361, rx: 216, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 26: tx: 443, rx: 298, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 27: tx: 325, rx: 180, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 28: tx: 398, rx: 252, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 29: tx: 346, rx: 201, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 30: tx: 474, rx: 329, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 31: tx: 323, rx: 178, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 32: tx: 349, rx: 204, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 33: tx: 202, rx:  57, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 34: tx: 462, rx: 317, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 35: tx:  87, rx: 422, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 36: tx: 407, rx: 262, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 37: tx: 354, rx: 209, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 38: tx: 377, rx: 232, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 39: tx: 435, rx: 290, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 40: tx: 456, rx: 311, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 41: tx: 466, rx: 321, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 42: tx: 349, rx: 204, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 43: tx: 328, rx: 183, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 44: tx: 385, rx: 240, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 45: tx: 115, rx: 450, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 46: tx: 297, rx: 152, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 47: tx: 332, rx: 187, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 48: tx: 298, rx: 153, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 49: tx: 432, rx: 286, (tx-rx):  146, (480+(tx-rx))%480: 146
> > 50: tx:  99, rx: 434, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 51: tx:  96, rx: 431, (tx-rx): -335, (480+(tx-rx))%480: 145
> > 52: tx: 380, rx: 235, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 53: tx: 417, rx: 272, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 54: tx: 272, rx: 337, (tx-rx):  -65, (480+(tx-rx))%480: 415 < NOK
> > 55: tx: 391, rx: 246, (tx-rx):  145, (480+(tx-rx))%480: 145
> > 56: tx: 305, rx: 336, (tx-rx):  -31, (480+(tx-rx))%480: 449 < NOK
> > 
> > what went wrong? (the pcm pointer w/dma pos never missed that
> > greatly)
> 
> I see your point.
> 
> > Very unlikely that an IRQ just happened to come in between the
> > register reads..with that frequency (> 1/50)
> 
> I don't think that this has anything to do with IRQ, it looks to me more like an 
> 'accident' in the timing of the reading the buffstat registers.
> 
> > so subjectively XBUFFSTAT / RBUFFSTAT are not useful for
> > any "real" use...
> 
> Well, yes and no. we can get good estimation with this I think still.
> 
> > 
> > - Eero
> 
> How I see this:
> In your code, you have a sysfs file, which can be read from user space.
> User space semi randomly reading that file to get the buffstat values.
> These registers are reflecting the buffer state on the L4 clock domain, which 
> means that the actual value might differ.
> So I think what happens is, that the user space happens to read the buffstat 
> registers most of the time, when neither the TX or RX is buffer has burst DMA 
> access, but time to time you can hit a point 'by accident' or just because of 
> the state of the moon, when either of the TX or/and RX is actually under DMA 
> burst. Since this burst is fast, L4 domain register can not be updated as 
> frequently, so it will reflect a bit later state of the buffer. If this happens 
> you will have inconsistent relation between TX and RX.
> 
> But I think, if you have similar sysfs file for comparing the DMA pointers you 
> will also hit the same spot.

Don't recall so. Maybe the DMA pointer is not updated during a burst at
all.

> If you happened to read the pointers when one of the stream is in DMA burst, 
> than you will definitely have the same problem.  
> So the DMA pointer comparison is 'correct' when neither of the stream are in DMA 
> burst.
> Same goes for the buffstat registers: if neither of the streams are in burst 
> they will provide pretty good numbers.
> 

I guess that depends on the use case. "laissez-faire" style applications
could just swallow that - but applications requiring perfect numbers are
in deep trouble.

> Since the pointer callback is naturally called after a period has been sent, the 
> DMA is not in burst anymore, so the reading of buffstat on the given stream will 
> give close enough estimation on the delay caused by the FIFO.
> 

It's always called at that point, but the user may be interested of that
at any given time.

> But yes, as you mentioned in your mail, this estimation can be done using 
> timestamp in DMA completion handler, and than calculate the delay based on the 
> timestamp we got, the threshold, and the size of the FIFO on the given McBSP 
> port.
> 
>