[pvrusb2] pvrusb2 and Fedora 11 - Audio cut after sometime of capturing

[Alejandro Vaquero]

Thanks Mike! My previous working configuration was F6 (not F11).
Another think to mention (probably is not related with pvrusb2 driver 
but MythTV) is that I'm having other audio issues with F11 and MythTV. 
During playback of a recording program, usually audio is ok but if I 
forward/rewind, sometimes the audio is lost so I need to exit the 
playback and try again to get the audio back.

Thanks
Alejandro

Mike Isely wrote:
> On Tue, 18 Aug 2009, Alejandro Vaquero wrote:
>
>   
>> I tried a couple different vanilla kernels from kernel.org, but so far no
>> improvement. Here the kernels installed:
>>     
>
>   
>>   kernel 2.6.30.4: Could not boot the machine with this one (got some kernel
>> panic message)
>>   kernel 2.6.27.29: Could not boot the machine with this one either.
>>     
>
> There might need to be a module in your initrd that you need here.  Just 
> guessing (having been down that road before).
>
>
>   
>>   kernel 2.6.29.6: Machine works fine but still have the same issue (audio cut
>> after some time while capturing from 29xxx) . This is the same issue as
>> running the F11 kernel 2.6.29.6-213.fc11.i686.PAE
>>     
>
> OK, so this is an important clue.  You're running a vanilla kernel and 
> still you have the audio problem.  That rules out Fedora-introduced 
> issues into the kernel.
>
>
>   
>>    Here the procedure used to compile the vanilla kernels (in case I'm doing
>> something wrong):
>>   1- copied the F11 kernel config to my kernel source dir:
>>          # cp /boot/config-2.6.29.6-213.fc11.i686.PAE .config
>>   2- Run
>>          # make oldconfig
>>       This asked a couple of questions depending which kernel was compiling. I
>> choose all defaults.
>>   3- Compile and install the kernel:
>>          # make
>>          # make modules_install
>>          # make install
>>     
>
> That's a good first cut; it's what I would have done.
>
> As for the underlying problem...
>
> Once the device is streaming there really isn't much else for the 
> pvrusb2 driver to do except to keep shoveling the bits that come out of 
> the hardware.  It's worth noting here that when I say "bits" what I mean 
> is the final mpeg stream from the hardware - after the audio and video 
> subchannels have been combined by that hardware.  Thus if the audio 
> "stops" yet the video keeps on going there's not a lot that the pvrusb2 
> driver itself could be doing to cause this.
>
> I re-read your original description and one of the things you mentioned 
> is that you have both a 29xxx and a 24xxx device but the problem only 
> happens on the 29xxx device.  That is another interesting datapoint.  
> The hardware is different in the two cases, but the meaningful 
> differences as far as audio is concerned involves the sub-device driver 
> used by the pvrusb2 driver and not the pvrusb2 driver itself (mostly).  
> Your 24xxx device uses a cx25840 type of part to process both the audio 
> and the video (into a form that the cx24116 mpeg encoder requires).  
> Your 29xxx device uses an msp3400 type of part to instead process just 
> the audio (an saa7115 does the video side).  The way the pvrusb2 driver 
> handles all of this really comes down to just selecting and setting up 
> the sub-device driver.  Once set up, the pvrusb2 driver sends the same 
> V4L commands to that driver, regardless of which one it is.
>
> So, if your 24xxx works but the 29xxx does not, then I'd suspect that 
> either your 29xxx device has a hardware problem, or that the msp3400 V4L 
> driver (msp3400.ko) is having a problem.  However you said this all 
> works in F10 so that would rule out a hardware problem with the 29xxx 
> device.  Very likely there are changes in the msp3400 driver included in 
> the different kernels with those Fedora releases.
>
> With the additional evidence that you managed to reproduce the problem 
> with a vanilla 2.6.29 kernel, that's something I should be able test for 
> here.  Most of the development work I've been doing has been under 
> 2.6.27.x as of late.  However I've jumped into 2.6.29.x a few times to 
> test changes that I know only come into play there.  I haven't beat on 
> that kernel a lot (mainly because I've had another unrelated problem 
> with that kernel version which nearly wrecked my root file system so 
> I've been loath to do a lot of testing there).  In particular I probably 
> haven't done enough testing with that kernel on a 29xxx device.  But now 
> that you're seeing a problem that I should be able to reproduce I'll 
> give it a try and let you know if I find something.
>
>   -Mike
>
>