First of all, thank you very much for taking the time to answer my concern.
On Sat, Jul 19, 2008 at 01:51:57PM (GMT-0500), Mike Isely wrote: > Given that the same chip-level driver is being used, then the only > possibility would be a mis-configuration of the chip. But there have > been changes in that area since 2.6.18, so before we start chasing that > it's probably best that you move up to the latest pvrusb2 driver first. Ok, finally got the time to test the following configuration: 2.6.18 + pvrusb.ko compiled from pvrusb2-mci-20080629.tar.bz2 + the last firmwares available on ivtvdriver.org (ivtv-firmware-20080701.tar.gz). The result is still the same: no problem with ivtv, same drift with pvrusb2. However, after giving it some more thoughts, I couldn't guaranty that the difference of behaviour I noticed when I upgraded ivtv wasn't induced by another factor. Indeed, I switched the PVR250 from one host to another approximately at the same time I upgraded the driver. So I tested something else. I recompiled ivtv-0.1.10-pre2-ck107t for 2.6.18: of course, it needed a few hacks; and even if I could make it record something, I am not too sure what it is. However, this test is still of some interest since with exactly the same environment (same hardware, same kernel, same modules, same firmware) except ivtv.ko, I observed once again some PTS issues in the generated stream (although this time they don't drift away, they oscillate around an average value). So IF we consider that the source changes I made didn't alter the test (and were sufficient to have a functional ivtv.ko), it WOULD seem there is something that can be done in the driver to correct the drifts. Thanks ! -- Boris Dorès _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
