[gmpi] Re: 3.9 Time wrap up Try #1
- From: "Martijn Sipkema" <m.j.w.sipkema@xxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 9 Mar 2004 19:34:53 +0100
> On Tue, Mar 09, 2004 at 07:15:38PM +0100, Martijn Sipkema wrote:
> > > Martijn! Wake up and convince us? I just want one good reason why it
> > needs
> > > to be part of GMPI and not a platform-dependant thing (like a
syscall).
> >
> > one would not need UST. If a plugin _does_ need to relate the MIDI and
> > audio time to some other time, e.g. a video or display device, then
you'd
> > need UST to accurately relate these different clocks.
>
> Mike Berry (from the Premiere group at Adobe):
>
> "I believe that all of the systems we are talking about running on
> have some form of independent clock. So if the plugin needs it, it
> can do it with a system call, or if it is cross platform, it can
wrap
> the system calls per platform...While there may be a bit of utility
> (for plugins) added by having GMPI do the wrapping (i.e., making
the
> host do the wrapping), I think it is more than offset by the
> complexity of having another time..."
You can't obtain the time (UST) for a frame (MSC) from within a GMPI
plugin accurately (if at all). This timestamping is best done at the audio
driver level or if that is not possible from the host application.
> > So I guess the question is whether this external (as in outside GMPI)
> > sync is needed. I don't see where the problem in supporting UST lies
>
> Well, we did decide early on that anything outside of GMPI is outside of
> this spec...
So only obtaining a UST/MSC pair needs to be in the GMPI spec.
> > though; all that is needed is to be able to obtain UST/MSC pairs in
> > order to relate the audio frame clock (MSC) to the UST clock.
>
> The "problem" is that it becomes an aspect of the requirements and the
spec.
> We will need to spec it fully, we will have to define it for each
platform,
> and all hosts will need to implement it.
>
> Implementing it may be as simple as a call to gettimeofday() once per
> process() loop. But we don't know that because we haven't fully specced
out
> what we need..
UST support could very well be optional I think. And the exact source for
the UST clock would be implementation defined. Calling gettimeofday()
(or better clock_gettime()) would have to occur in a high priority
thread at the beginning of the process cycle. If you have reasonably large
process cycles and high system load then obtaining the time from within
a plugin could possibly be more near the end of the process cycle than its
beginning introducing significant timing jitter.
--ms
----------------------------------------------------------------------
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:
