[gmpi] Re: Time Summary (was *Ping*)
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 20 May 2003 00:33:16 +0200
On Monday 19 May 2003 23.45, Tim Hockin wrote:
> > The normal way would be to pass events to process(), and those
> > would
>
> Without getting into implementation, let's just say that the normal
> event delivery is to enqueue events up to the instant that
> process() is called for a plugin.
Yes. That's what I actually meant.
> > Plugins that are implemented in a way that allows them to respond
> > to events delivered during the process() call, or while waiting
> > for an asynchronous process() call (VST style) to finish, could
> > implement a separate, thread safe entry point for event delivery.
> > Events
>
> So these are events that occur for the current timeslice but occur
> after the start of the process() call.
Yes - although their asynchronous nature means there's a risk they
don't even hit the current timeslice. A scheduler hickup, and the
events may end up after the *next* process() call.
Also note that we'll probably need a feature that allows process() to
return before the actual work is done, and a way of notifying the
host upon completion. VST has such a feature, and AFAIK, it's
specifically meant for plugins that wrap DSP hardware and the like.
(No point in blocking the whole audio thread in process(). The host
might have other things to do that doesn't depend on the output of
this plugin.)
> > delivered through this entry point are not hard real time, and
> > not guaranteed to be in strict sync with audio time as seen by
> > process(). That is, even though events are timpestamped, they may
> > arrive before the buffer they're meant for, or too late for the
> > intended timestamp to be respected. Plugins are required to deal
> > with this in a suitable way.
>
> How could they arrive too early? I can see how they would arrive
> with a timestamp that just passed...
Well, I could probably think of an example, and a way to "fix" it, but
it doesn't really matter, I think. The point is that the asynchronous
events break the whole timestamp order thing, so plugins must adjust
timestamps and then sort/insert or whatever works for them.
> What I dislike about this idea is, again, inconsistency. Some
> (most) plugins will have latency equal to the host-defined latency.
> Some will have less. While it's hard to say that less latency is
> bad, inconsistency IS BAD.
Yes, I agree, and I'm not convinced that cutting the best case or even
average latency is worth the effort. In my experience, fixed latency
is a huge improvement over "deliver ASAP" designs, *especially* when
the total system latency is high.
It's just that some people think it's an important feature, and I'm
trying to come up with a solution that does the job well for them,
without making life misserable for the rest of us. Forcing every
plugin to have a separate, thread safe entry point for events is just
not an option, IMNSHO.
> Do we really want to go this route, or can we just say that you
> always want the lowest latency possible.
As in, asynchronous events are delivered for the next process() call?
(As you would do with XAP or any other API that doesn't have a
separate, thread safe event interface.)
> If we do want to go this
> route (and also the route of higher control-latency plugins), does
> it need to be in GMPI v1.0?
With my solution; no. All it requires is a hint for asynchronous event
inputs, and an extra plugin callback entry. Both are optional both
ways, so adding them doesn't break anything.
BTW, how about plugins *sending* events asynchronously? I guess the
only sane way of dealing with that would be to use a host call for
the sending, rather than writing directly to event queues. That would
allow the host to sync the event delivery so that it doesn't collide
with other plugins or the host itself sending to the same async
target at the same time.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
