In that case, I thank you for sharing this idea, it's much appreciated.
Right now, I schedule a thread to restart audio should I detect overrun, but
I like your idea more.
thanks,
Philip Lukidis
-----Original Message-----
From: Tommy Schell [mailto:email@hidden]
Sent: Wednesday, October 19, 2005 1:43 PM
To: Philip Lukidis
Cc: FW Liste
Subject: Re: Subject: listen DCL program woes
I'm referring to the same isoch document that you were referring to.
The self looping mechanism is my idea, which I came up with after
a great deal of struggle trying to get a smooth overrun recovery.
It works quite well, for me.
So that part isn't documented.
On Oct 19, 2005, at 10:00 AM, Philip Lukidis wrote:
> Thanks for your answer. Could you please point out the source of this
> documentation? Somehow this does not sound familiar to me, though I
> do understand your point. I should read this fully.
>
> As far as I know, I have not detected an overrun, and the same test
> passed OK on a G4, which is quite slower than my problematic G5.
>
> thanks,
>
> Philip Lukidis
>
> -----Original Message-----
> From: Tommy Schell [mailto:email@hidden]
> Sent: Wednesday, October 19, 2005 11:20 AM
> To: Philip Lukidis
> Cc: FW Liste
> Subject: re: Subject: listen DCL program woes
>
>
> This doesn't answer your question, but I put a safety mechanism in my
> Firewire DCL program
> (actually NuDCL program) where if an overrun occurs, I do a self loop
> on the last buffer to
> prevent an actual overrun.
> So I have a 3 buffer safety zone as the documentation suggests, and
> with the 3rd buffer,
> at the end I jump back to the beginning of the 3rd buffer.
> If the hardware gets too far ahead of the software, the hardware is
> then held in check.
> That way in the event of an overrun (which happens from time to time
> on my G4), things don't
> fall apart, I just lose a couple frames (video frames, in my case),
> and then things go back
> to normal.
> And then with each callback, I move the 3 buffer zone forward 1, and
> adjust my jumps appropriately.
>
> Tommy
>
>
> *************************
>
> Message: 1
> Date: Tue, 18 Oct 2005 09:30:17 -0400
> From: Philip Lukidis <email@hidden>
> Subject: listen DCL program woes
> To: email@hidden
> Message-ID: <79710AF8DF7794458457EAF404E82431053E7B68@GCMTLEXC>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello. I have problems with my listen DCL program, in that it
> eventually
> stops running (callbacks cease, as least). It has the overrun
> detection
> system as discussed in the isoch DCL html document (if the overrun
> proc is
> called, it means that the jumps were not modified in time, and
> overrun has
> occurred). I do not believe that overrun has occurred, though, due to
> driver debug output, and that it does not occur on some slower
> machines.
> This problem occurred after many hours only. It seems that my play
> DCL
> callbacks are being called, though. Unfortunately I don't know if a
> fatal
> OHCI error occurred (handleUnrecoverableErrorInt) because the IOLog is
> swamped with debug output (firelog was not on at the time).
>
> Is there any other reason for a DCL program callbacks to stop being
> called?
> Unfortunately I didn't have debug OHCI installed, and so I cannot use
> mr.
> registry to any effect. I have listed my DCL program below.
>
> thanks,
>
> Philip Lukidis
>
> Record DCL program listed here (note that there is one dummy receive
> at the
> end if overrun is detected- it does not have an update called on it):
> kDCLLabelOp [0x3235a400] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232903c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a558 (x1)
> kDCLLabelOp [0x3235a558] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232905c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a6b0 (x1)
> kDCLLabelOp [0x3235a6b0] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232907c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a810 (x1)
> kDCLLabelOp [0x3235a810] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232909c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a968 (x1)
> kDCLLabelOp [0x3235a968] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290bc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235aac0 (x1)
> kDCLLabelOp [0x3235aac0] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290dc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235ac24 (x1)
> kDCLLabelOp [0x3235ac24] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290fc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235ad7c (x1)
> kDCLLabelOp [0x3235ad7c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232911c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235aed4 (x1)
> kDCLLabelOp [0x3235aed4] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232913c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b038 (x1)
> kDCLLabelOp [0x3235b038] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232915c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b190 (x1)
> kDCLLabelOp [0x3235b190] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232917c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b2e8 (x1)
> kDCLLabelOp [0x3235b2e8] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232919c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b44c (x1)
> kDCLLabelOp [0x3235b44c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291bc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b5a4 (x1)
> kDCLLabelOp [0x3235b5a4] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291dc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b6fc (x1)
> kDCLLabelOp [0x3235b6fc] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291fc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b85c (x1)
> kDCLLabelOp [0x3235b85c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232921c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b9b4 (x1)
> kDCLLabelOp [0x3235b9b4] (x1)
> kDCLReceivePacketStartOp size = 396 (x1)
> kDCLCallProcOp addr = 0x3135791c (x1)
>
>
>
_______________________________________________
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