I'm
using a legacy DCL program, and while I don't use timestamps for send (I do for
receive), I update after each group of SendPacketStart (is this
incorrect?). After each group of sends, I do a group update,
and the callproc follows, rinse and repeat, etc while tending to modifying
jumps. Is this ordering incorrect for a legacy talk (send) DCL
program?
[1
update here also for this dummy send] kDCLCallProcOp addr = 0x31273180
(x1) <----- overrun proc, should never be reached except under
exceptional circumstances
-----Original Message----- From: BlazeAudio Developer
[mailto:email@hidden] Sent: Friday, October 21, 2005
2:26 AM To: email@hidden Subject: Re:
TimeStamps with ischo. transfers
At 03:12 AM
10/21/2005, Niels wrote:
Hi Devendra
When your
update runs, the timestamp is copied out of the hardware program into your
time stamp buffer.
Aha! Perhaps this is where the
problem lies with isoch. sends.
For isoch. sends, the "update" has to
run "before" the packet is sent, correct?
[At least that's what the
requirement was with legacy DCLs]
In that case, the timestamp that is
copied to our time stamp buffer is actually invalid, or perhaps "stale".
Because up to that time(when the update is run), the data has not even been
sent, so how could it know what time it will be sent!
When you call
notify( kFWNuDCLModifyNotification ), the hardware descriptors for the
affected DCLs will be rewritten... your timestamps on the recompiled DCL may
no longer be valid, so inspect them before calling
notify().
Yes! I do inspect them before calling
notify()! But it's good to know that it's a requirement!
Does that
help?
Yes. I think this explanation (with the
update running before the data is sent) matches my
observations.
Thanks. Devendra.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Firewire mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/firewire/email@hidden
This email sent to email@hidden
