On Fri, Apr 5, 2013 at 9:28 AM, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > >> I thought that the timestamp and the runtime delay are basically >> independent parameters. Why must the former be disabled? > > > In HDA you have DPIB and LPIB. The position in the buffer is reported by > DPIB and the # of samples rendered is reported by LPIB. The delay is the > difference between the two when you use the LPIB_DELAY implementation. As a > result, when you look-up the timestamps and query the delay, what you get is > the current time as seen by the HDA interface. If you increment the runtime > delay to add the codec delay, then you must also increment by the same > amount in azx_get_wallclock_tstamp(). Just updating the runtime delay is not > enough. 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) > One problem I also have with this approach is that the delay may be > different if you have multiple streams processed with different algorithms, > and that isn't exposed here. > -Pierre > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
