Actually, I just reread the doc, which says that an update is
automatically done for transmit DCL commands (send) when the DCL program is
started, so I should be OK, as an update has been called once before each
sendPacketStart.
I'll
just further mention that I have two possible cases for send (I
have no timestamps):
a) I
call update on the sends before the send callproc.
b) I
call update on the sends after the send callproc.
Since
I don't currently use timestamps for send, either case should be fine,
right?
thanks,
Philip
Lukidis
-----Original Message----- From: Philip Lukidis
Sent: Friday, October 21, 2005 9:12 AM To: BlazeAudio
Developer; email@hidden Subject: RE: TimeStamps with
ischo. transfers
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
