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

[vdb128 at picaros.org]

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

Here I agree completely, the driver is not at all at fault.  

> 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 

Indeed.  When there is sync loss the mpeg stream contains video but 
no audio frames.  On resync the mpeg audio frames reappear with the 
correct timing tag.  

To reproduce:

1. tune to an unused frequency, 
2. record,
3. wait, tune to a used frequency, wait, foreground dd, and
4. stop recording.

echo 591250000 >ctl_frequency/cur_val
dd if=/dev/video0 of=/tmp/tmp.mpg bs=4096 &
sleep 10 && echo 639250000 >ctl_frequency/cur_val && sleep 10 && fg
#<now press ctrl-C>

Play this file through a pipe

mknod /tmp/t p
cat /tmp/tmp.mpg >/tmp/t &
mplayer -vo xv -ao alsa /tmp/t

and the audio initialization fails.  Use the file directly

mplayer -vo xv -ao alsa /tmp/tmp.mpg

and mplayer seeks to the future, inits the audio decoder, and complains

Too many video packets in the buffer: (4096 in 8088400 bytes)

since it synchronizes audio to local time and adapts video display.  Then 
audio starts at

A:  10.2 V:   2.6 A-V:  7.514 ct:  0.236  60/ 60 12% 11%  3.0% 0 0 

and the video playback rate is increased as to match image to audio.  

> 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 

I don't see any workarounds since 
1. The cx25840 doesn't signal loss of audio sync.  
2. The pvrusb2 driver might:
   - inspect the mpeg data -> not realistic due to CPU load, 
   - intercept lirc channel change -> do reset -> bad practice IMHO.  

So I think that the application is responsible here.  It should be able to 
handle changing stream parameters during playback.  If not, it should close 
the device during a channel change, reopen, and reinitialize.  

Servaas