[gmpi] Re: Time Summary (was *Ping*)

  • From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
  • To: "gmpi@xxxxxxxxxxxxx" <gmpi@xxxxxxxxxxxxx>
  • Date: Mon, 19 May 2003 09:16:54 -0400 (EDT)

On Sun, 18 May 2003, B.J. Buchalter wrote:

> If so, then this discussion is definitely beyond the scope of the current
> effort -- that is why I asked a couple of days ago if we could get a
> consensus as to whether or not this is beyond the scope of the current
> effort. I would like it to be within the scope since I feel that it would
> allow a standards based approach to a very hairy problem, but I understand
> that it is on the edge of what most folks may be currently interested in.

I think we should put it in the category of latency-compensation in
general.

> > Yes, and for certain classes it would also be nice to be able to
> > account for audio latency (both data-latency and time-latency).

> I'm not sure that this is a "nice" thing. I think it may be a required
> thing.

It's also a rather difficult thing, and if we're not careful how we
address it it will complicate implementation for all kinds of things which
otherwise wouldn't need to know about it. We need to be careful not to
burden plug-ins with having to understand this stuff.

> This is a very good point, and may be the crux of the biscuit. Although, you
> still could propagate the sum of latencies through the graph and slip the
> audio for such a plug (which is what you would have to do with an audio
> latency). I'm still not clear that you cannot handle this aspect
> symmetrically with audio delay, with the exception that my approach allows
> independent audio streams proxied by GMPI to operate with minimum latency,
> and the "everything is an audio latency" approach does not.

Yes, I see what you mean there. If we're talking about minimum-latency
communication to devices running outside the GMPI audio latency timeslice,
then "everything is an audio latency" does not work. To be honest though I
think that's getting outside the spec.

> So, the EventProcessor processes the event stream generated by
> AudioToEventConverter from audio 1, but the output of APWithAudioLatency
> is propagated with some latency. This means to time-align the output of the
> APWithAudioLatency , the event processing terminal of EventProcessor needs
> to be time-aligned and propagated back to the Audio 1 stream sent to
> AudioToEventConverter. This is all within the same GMPI graph, but it is
> exactly the same issue as what I am talking about -- the control stream has
> some latency to the effect. Either we handle this case, or the above will
> not be time-aligned, and the user will have to slip the stream.

Agreed. We will need to support this if we support general latency
compensation.

> > So the host now has additional latency on the setting of its loop points.
> > You've just added latency to the whole system.
>
> I don't understand what you mean here. Could you amplify?

Sure. You've already sent the loop point in advance, so now you cannot
change it.. it is set in stone. Therefore, any change to the loop point
has to be set in advance... you've propagated latency to the loop point
control on the sequencer.

> Yes. Probably. But not necessarily. For example, with Firewire we can have
> dedicated bandwidth for audio transport, but control transport would be
> asynchronous and can have scheduling latencies different from the audio.

Not necessarily. If we want GMPI-compliant control transport, we will have
to transport the control data isochronously as well. That can be done,
although it then puts a ceiling on control event density.

Regards,
        Angus.


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