On Wed, Feb 04, 2004 at 05:30:20 -0500, Paul Davis wrote:>On Wed, Feb 04, 2004 at 12:51:58PM -0800, Chris Grigg wrote: >> Speaking of multiple time coordinates that could conflict, can >> someone remind me again why an event needs both sample clock and UST? >> What does the plug do when they don't agree, pick whichever one it >> like better? > >I think events only ever have ONE timestamp - the absolute/master/sample >clock. If a plug wants to know the UTC for a sample value, it can ask the >host.
minor nit: i am not sure what UTC stands for, but i am pretty sure its unrelated to UST (Unadjusted System Time).
Coordinated Universal Time: http://www.ghcc.msfc.nasa.gov/utc.html Its the time standard to replace Grenwich Mean Time.
To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] Re: Topic 6: Time representation Date: Wed, 30 Apr 2003 09:43:06 -0400 From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
>> That said, what absolute format should we use:- Samples (64 bit)? - Seconds (double precision float)? - Something akin to "reference times" (64 bit, each unit = 100 nsec) - Other?
we've discussed this a lot recently in the context of JACK's transport mechanism. i believe that the consensus has been that we actually generally need 3 absolute times:
* sample clock (frames, 64 bit integer) * UST (nanoseconds, 64 bit integer) * musical time (ticks, 64 bit integer) (obviously requires nanoseconds-per-tick to be available to make it usable, plus tempo map info to make it useful)
"UST" is an acronym that comes from IRIX (i believe) though it has been more widely used since. it stands for Universal System Time, and is typically derived from something like the cycle counter. however, this is an implementation detail: the OS just provides it (POSIX specifies an API for this). the key elements are that it is absolutely monotonic, and will return consistent values across a defined "host" (typically a given computer, but not necessarily).
the reason you want to provide UST as well as the sample clock is so that plugins that interact with other streaming clock sources (e.g. video) can have a common reference clock for the different clocks they have to sync between. that is, they can say "well, the UST for sample clock N was ...., so deliver this video data at UST = ....". without this cross-stream-clock reference, sync becomes much more complex. and yes, for video there are often other solutions, but there are (and will be) other kinds of streaming clocks where this not true.
also, we need to agree on what the sample clock actually represents. is it a "transport time" (also called "media time" by some), or is it a free-running clock that began at some point in the past and runs monotonically toward the future?
finally, we need to define when its possible to get time information. my preference is for it to be only possible during the process() callback (or equivalent). this allows the host to set up time information once, and then have plugins query it subsequently without any recomputation. the information returned by the query refers to the time corresponding to the start of the buffer(s) being handled by the callback.
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe