Thanks for the explanation Pierre, but I'm still a little confused. Does the timestamp represent the time the last sample was put in the buffer or the time the last sample was rendered to the bus? Is the "current time" meant to be the timestamp that the next sample sent will be rendered? (timestamp + delay)
When you query with snd_pcm_status(), you get all sort of information, including 2 timestamps. The 'regular' timestamp is just the system time (tsc) and the 'audio' timestamp is the time as reported by the audio hardware. This can be inferred by reading sample counters (# of samples pushed on the serial link) or wallclock counters, the wallclock is essentially identical but gives you a higher degree of precision. The audio time really needs to be taken at the last possible stage, not when you write into a buffer. The two timestamps can be used to find out what the drift is between the two time references (eg in PulseAudio) In other words, if you add the codec delay, it's fine but it needs to be accounted for in a symmetrical manner, otherwise the audio timestamp and the delay will be off by a fixed amount. Correcting the wallclock value and substracting the codec delay in azx_get_wallclk() would realign accounting methods.
-Pierre _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
