[gmpi] Re: Topic 6: Time representation
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Apr 2003 09:43:06 -0400
>> 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
Other related posts:
