On Fri, Apr 5, 2013 at 2:24 PM, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > >> 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)? > > > Yes, correct. > > >>> 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? > > > If wall clock is supported, audio timestamp doesn't account for codec delay > If Wall clock is not suported, audio timestamp does account for codec delay > with your patches. Good, I get it, thanks for the education! > > >> 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. > > > My suggestion is that the audio timestamp always accounts for codec delays, > which will allow you to track drift and track rendering time. Btw for > capture wallclocks are disabled for now since we don't really know how to > use them for digital inputs, and we really need to have a consistent > behavior for capture and playback. Sounds good, I'll take a look at adding the delay to the wallclock time as well. > -Pierre > > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
