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