[pvrusb2] New driver snapshot: pvrusb2-mci-20090616

[Mike Isely]

On Mon, 22 Jun 2009, vdb128 at picaros.org wrote:

> > So what you're telling me is that you're not actually changing any state 
> > within the device itself - because you're just using the s-video input.  
> > Yet when you change channels on the upstream source, the audio is gone?  
> > 
> > The pvrusb2-driven device cannot "tell" when there is or isn't audio 
> > coming into its line-input - it's just an analog unmodulated audio 
> > signal same as what any stereo system component would work with.  
> > There's no concept of an audio signal being "present" or not so I don't 
> > understand how the device could choose those instants in time to lose 
> > the audio.  Are you sure that you're not actually (deliberately or 
> 
> Well, actually the cx25840 audio into video stream embedding is locked to the 
> field dot clock.  Audio is inserted in the horizontal blanking of the bt.656 
> word stream.  This is good since A-V sync is so guaranteed before cx23416 mpeg 
> encoding.
> 
> If you are capturing, dd if=/dev/video0 of=tmp.mpg bs=4096, from an external 
> receiver and change the receiver's channel either the following happens:
> 
> 1.  Loss of hsync is declared -> resync -> no data from video0 for about 1 s.
> 
> 2.  The phase of the new hsync signal is close to the previous signal, 
>     perhaps upto 16 dots or so, and is considered as video timing jitter.  
>     Then the embedder compensates.  This is in the cx25840 specifications if 
>     memory serves.
> 
> 3.  The frequency of the new hsync is equal to the old but the phase is off 
>     ... no audio.  This last statement is just my guess.
> 
> I had the same behaviour when capturing from cable through a VCR but only 
> for specific channel combinations.  This was using pvrusb2-mci-20070407.
> 
> All the above is just my view, not a critic, 
> Servaas

Servaas:

You need to take over maintainership of the cx25840 module.  This is way 
beyond anything I know about that chip!

My point in my earlier post is that for the driver to do something wrong 
at the point when the audio got lost, then the driver first has to do 
*something* at all.  If he is just capturing from s-video and only doing 
something to the signal itself but not actually calling into the driver, 
then there's not a lot that the pvrusb2 driver can do to help or hurt 
that situation.

Mark followed up with two more important bits of information however:

First that MythTV may itself be doing something to the driver at the 
point of the channel change even though whatever it is doing is 
effectively a nop in the end (so perhaps the driver might be doing 
something to cause a problem).

Second he added that when later played back a recorded stream (live tv 
buffer) that previously had no audio - he got audio from it.  So clearly 
the audio must have been recorded anyway and probably MythTV's playback 
algorithm had a problem at the point when the signal content was 
switched.  Obviously there has to be a momentary disruption in 
synchronization since the two sources can't be gen-locked.  Beyond that 
I don't know what to suggest.

I can ask two questions to you, given your knowledge of the chip:  Is 
there anything we can do in the cx25840 driver that would ease this (and 
can you submit a patch for it)?  Alternatively is there anything the 
pvrusb2 driver might be able to do at the point when the stream is 
interrupted - assuming that driver can do anything at all since the 
disruption in this case was upstream of the device?

  -Mike

-- 

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