[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 23:21:01 +0100
[...]
> >>Perhaps more important than just UST, is the relationship between UST
and
> >>the GMPI clock.
> >
> > UST is meaningless without that. It is about UST/MSC pairs (where MSC is
> > the audio frame clock).
> >
[...]
> > Using UST/MSC pairs a plugin can estimate when a frame will be
performed.
>
> I guess I'm not yet convinced. For this to work, I believe that the
> plugin process has to be called on the audio callback thread so that the
> timing stays locked.
No, that is not true. In fact UST is needed just because the process() does
_not_ have any relationship (that can be used) to the audio clock. SGI uses
UST/MSC with an asynchronous audio API.
The MSC is a frame clock, i.e. increased for every audio frame. The plugin
has no idea when a certain MSC will actually be performed. By obtaining
a UST/MSC pairs it can relate the MSC clock to the UST clock and thus
know when an audio frame will be performed in relation to other events
of which it knows the UST time.
> But imagine this case. All that the host does on the audio callback
> thread is copy into the output buffer and return. Meanwhile, some other
> thread is simply chugging along rendering audio and placing it into the
> buffer to be copied. Now the render time of the plugin is pretty much
> decoupled from the audio clock. (If this doesn't sound familiar, think
> DirectSound :). In a sense, the other thread is an "offline renderer."
> This is a completely reasonable host model, but it seems to destroy the
> possibility of providing a useful UST. So is UST optional by the host?
> If it is optional on some hosts, then all plugins will have to work
> around the possibility of not getting it. So is it still useful?
The host should be able to provide UST/MSC pairs to the plugin; the
plugin could ask for a new UST/MSC pair at some constant rate. This
allows the plugin to estimate the sample rate relative to the UST clock
and estimate the performance time for a future sample (MSC).
UST is especially useful in this case because there is no other way to
relate the audio time (MSC) to any other time, e.g. display/video.
See also http://www.lurkertech.com/lg/time/intro.html.
--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:
