[gmpi] Re: Reqs 3.9. Time - opening arguments.1

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 15:35:30 -0800

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

 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.

- Steve

I'm sure he meant UST. And I found the origin, see below.

-- Chris G.

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

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

Other related posts: