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

[vdb128 at picaros.org]

> 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