Re: [Deinterlace-discuss] Another bug to fix

[Torsten S. <Tor...@t-...>]

Rob Muller wrote:
> The problem I was seeing was that start-up or channel switching did
> not always work. About one in 20 or so start-ups were not successful,
> no image mostly ('reset card' needed to get it to work). With channel
> switching one in 100 times or so was not successful. After fixing a
> bug in the i2c timing code (overflow, the bad timing was way off) the
> new version of DScaler *never* had problems again with initialization
> or channel switching. Normally I only use official DScaler releases
> on a daily basis, not the latest CVS code (so this is well over a
> year now) so it is possible that some other bug-fix is responsible
> for the improvement but at the time I could not spot another bug-fix
> that could explain the improvement.

Ah, thanks for let me known. Thats new for me.

>> That makes me wonder, see file SAA7134I2CBus.cpp
>>
>> All I2C traffic to the SAA chip is done via hardware. No moving the
>> SCL/SDA lines by hand is requierd like on the other chips
>
> Can this explain why the SAA7134 card I have works much better than
> the other cards? With the other cards problems like bad
> initialization or unsuccessful channel switching is much more common.
> Note that this is the exact reason for me to improve the i2c timing,
> it would be great if the stability of all cards would be as good as
> with the SAA7134.
>
> Do you also see these issues with your CX card?

I2C is the best that works for me atm with current cvs ;)

I have no issues with my cx card and as far I remember with an bt card some
time ago too. I could be wrong but from feeling it does not depands on
capture chip but on the machine you have. Mine is a bit outdated (1.8GHz,
@512MB, GeForce2), maybe the reason why no overflow occurs in waiting loops.

> I am not against this but I think other things have more priority
> like the mess that is called WorkoutOverlaySize or the entire timing

You are right, some other things have to fixed first.
With current cvs no combobox is working. When using D3D output I have
13DF/S. And so on. Very instabily atm.

> stuff in Dscaler. Why do we need nanosecond timing code that consumes
> all CPU cycles when there is the refresh rate of the monitor that
> sets the pace?

That is true. Is there no other way for waiting?

Torsten