[pvrusb2] MPEG PTSs drifting away

[Mike Isely]

On Mon, 21 Jul 2008, Boris Dores wrote:

>   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.
> 

Boris:

This definitely has to be a problem with the way the pvrusb2 driver is 
configuing the cx2341x module.  There really is no other explanation 
here since it's cx2341x that actually controls the chip which ultimately 
is generating the data that you see is drifting.  And it can't be the 
cx2341x module itself because the same code is shared between both 
drivers (it is a module in v4l-dvb used by both drivers).  So to figure 
this out we need to compare how they are being set up.  Care to do some 
digging on this?

The code in question will be found in pvrusb2-encoder.c.  Look at 
pvr2_encoder_configure().  For the standalone driver there are two 
versions, conditioned by the PVR2_ENABLE_CX2341XMOD ifdef.  The version 
where the ifdef is off corresponds to not using the cx2341x module, the 
other is just a wrapper around calls into cx2341x.  The actual settings 
are not here, but you can probably put some debug code at this point 
(and/or in pvr2_encoder_adjust() which this function calls) to "spy" on 
what the pvrusb2 driver is telling cx2341x...

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8