[gmpi] Re: Topic 6: Time representation

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 30 Apr 2003 12:18:36 -0400

>Remember that music time can have relatively complex tempo maps, so it's
>relatively complex to convert, especially when in the vicinity of a
>tempo curve. I agree that the relationship of sample time to UST time
>can be essentially fixed.

unfortunately, its not fixed at all. 

you may be running with a varispeed sample clock. you may have an
exceptionally poor cycle counter on the CPU as the source of UST. you
may derive UST from the atomic clock in colorado, against which most
sample clocks will drift randomly. you may just have a soundblaster
with its wretchedly pathetic sample clock. etc.

the whole reason why you need UST as well as the sample clock is
to define a single cross-referenceable time base against which other
clocks outside the scope of GMPI can be "stamped". more specifically,
when scheduling things for asynchronous delivery (i.e. not continously
streamed data like audio or video), scheduling uses UST because the
sample clock is not (or may not) be available to the scheduling
mechanism.

--p

----------------------------------------------------------------------
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: