[gmpi] Re: Time Summary (was *Ping*)
- From: "B.J. Buchalter" <bj@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 16 May 2003 11:14:58 -0400
on 5/15/03 8:35 PM, Tim Hockin at thockin@xxxxxxxxxx wrote:
> 4) Events are only sent for the current timeslice
I have a comment about this and a question (without an answer).
There is an implicit assumption here that the host is "running" the graph,
and is absolutely controlling the processing timeslice (or buffer) and has
full control over the sequence of posting events and then initiating the
timeslice for processing. While this is true in the case of host-based
processing, it is not necessarily true in the case where the graph is
running remotely (say on a DSP card or another computer). With most current
DSP accelerated plug-ins, it is still the case that the plug-ins are running
in the host's graph (they transport audio to the DSP based upon the process
time slices), so they fit the model proposed here quite well (events just
must be transported with the audio to the DSP). There is another model that
must be considered however, which is where an entire graph (or sub graph) is
being run remotely, with potentially large or unpredictable latencies in the
communication channel between the host and the remote processor exist (e.g.
Ethernet). Obviously this presents a challenge for immediate live events as
has been discussed before, but, in principal, it should be possible for
timestamped events to be delivered to the remote graph in a predictable way,
and for the proxy to be able to translate the timestamps between the two
(synchronized) clock domains. However, this may require the host to deliver
timestamped events before its conception of the "current timeslice" in order
to provide enough time to overcome transport latency and jitter.
Is it possible that we want to (or need to) allow a plug-in to define a
"timestamp" lookahead time that causes the host to deliver events before the
current timeslice in a well defined way? This is not to allow a host or a
plug to queue up events forever into the future, but to allow the plug to
get a "short" look into the future so that it can compensate for any
internal delays between its event terminal and its process routine (which
could be halfway around the world (or at least in another physical box).
Or is this something that no one (besides me) is interested in?
On another note, I have a question for those folks who are against using a
double to represent ABSTIME. It seems to me that a double has 48 bits of
precision. This means that it can represent the integers from 0 to 2^47 with
no rounding. If this is in samples, this corresponds to 46 years or so with
no wraps at 96k. And current hardware can do most arithmetic operations on
these quantities in one cycle. So, am I missing something about scaling
precision and rounding? It seems to me that using a double for integer+
representation is very useful in this context (not that 64 bit integer
bothers me that much either, and in some ways is more transportable to most
DSP architectures). I understand how floating point numbers have strange
rounding and scaling precision behaviors, but I don't really see how this
comes into play for this application with the precision in the double (float
would definitely cause problems). BTW, this is not meant to start another
war on this subject -- I'm just wondering if the anti-double folks can show
me where I am missing the boat?
Best regards,
B.J. Buchalter
Metric Halo
M/S 601 - Building 8
Castle Point Campus
Castle Point, NY 12511-0601 USA
tel +1 845 831-8600
fax +1 603 250-2451
If you haven't heard ChannelStrip yet, you don't know what you're missing!
Check out SpectraFoo, ChannelStrip and Mobile I/O at http://www.mhlabs.com/
----------------------------------------------------------------------
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:
