[alsa-devel] Improving status timestamp accuracy

[Alan Young]

I am looking at ways to get more accurate status timestamp information 
for various SoC drivers. The data that is obtained by snd_pcm_status(). 
One route would be to implement the more accurate timestamp mechanisms 
that currently are only available for HDA and Skylake (which I think is 
the SoC version of HDA).

Looking at the code however, I think that may be unnecessary, at least 
for my purposes. It may not actually be practical in many cases.

A call to snd_pcm_status() result in snd_pcm_update_hw_ptr0() being 
called. This gets the current output position (pos) via 
substream->ops->pointer(substream) and then makes all the other 
calculations based on the result. In theory, the result of 
substream->ops->pointer() could be sample accurate but in practice it is 
very unlikely to be better than period accurate. In fact, if I read it 
right, it will just about always be accurate to the point of the last 
period interrupt. Even when a DMA driver claims support of 
DMA_RESIDUE_GRANULARITY_BURST, it is often the case that the actual 
granularity is a period.

The consequence of all that is that, for most drivers, the accuracy of a 
status report is period time. The result values, tstamp & audio_tstamp, 
are calculated using the current time and the pos estimate from above.

snd_pcm_update_hw_ptr0() is also called when there is a DMA interrupt. 
At that time the calculate results will be accurate, or at worst 
consistently inaccurate (there could be a constant offset). It would be 
useful if a snd_pcm_status() call would simply return the results from 
the point of the last interrupt, and not try to estimate a current value 
based on the inaccurate substream->ops->pointer() result. It could 
either: (a) return the result from the time of the last interrupt, in 
which case tstamp would be in the past and driver_tstamp would be now; 
or (b) update audio_tstamp based on the elapsed time since it was 
recorded. (b) effectively abandons the idea that a current position 
report will be accurate outside of an interrupt callback but, even if it 
is, doing so is unlikely to result in any loss of accuracy in practice 
(assuming a drift of better than 40ppm and period time < 100ms).

Any comments on either of these approaches? I guess (b) is more 
compatible with the current model.

Alan.