Re: [Deinterlace-discuss] Problems fixed

[Atsushi N. <at...@ch...>]

Rob Muller <rob...@gm...> wrote:
> When trying to find out what code uses the flawed functions I stumbled upon 
> InitializeSleep(). This code amazes me, what happens if the computer is 
> busy for just a few ms when this code is called?

There're a few crazy (not-so-scientific) code like this in DScaler. :)
I presume the code was initially put in place as an
I-don't-know-a-better-way-but-this-will-probably-do-for-now solution and
was never revised.  The SAA713x and CX2388x counterparts, perhaps
followed BT8x8's lead without following up.

There does indeed appear to be a problem with that code:  If the
computer is busy during InitializeSleep(...)'s cycle estimation stage,
it's possible to get a count that, when the computer is not so busy, is
far less than that required to provide the delay of the period of 50kHz.

I'm not certain why the sleep time used for I2C control needs to be
calculated in terms of a CPU loop cycle count.  Maybe there's a
performance overhead in using the high performance timer
(i.e. QueryPerformanceCounter(...)).  However, for SAA713x's
GetNextField(...) operation, I recall I poll the high performance timer
when waiting for each field..

Maybe Sleep(...) can be changed to just poll GetTickCount(...) the way
it's done in InitializeSleep(...)?

(In a similar failure of foresight (rather, from laziness), I've put in
few code for SAA713x that takes certain state changes by the hardware
for granted and polls for them without a timeout. :))

Regards,


-- 
Atsushi Nakagawa
<at...@ch...>
Changes are made when there is inconvenience.