On Fri, Apr 5, 2013 at 10:20 AM, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > >> 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) I think I'm starting to understand this. To go just a little bit deeper: Is the 'audio' timestamp the one calculated in snd_pcm_update_hw_ptr0, based on either the hardware or the delay (INFO_HAS_WALL_CLOCK)? > 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. Would this problem manifest on systems that don't support wall clock? Because the time based on delay will contain the codec delay? There are two distinct use cases: Wanting to know how the audio clock is drifting with respect to the system clock. (don't care about codec delay) Wanting to know when a sample will be rendered for AEC or A/V sync. (codec delay critical) Can we keep them from affecting one another? This seems possible if the timestamp and delay are reported separately. > -Pierre > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
