[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..

[Andrea Venturi]

Mike Isely wrote:
> On Mon, 7 Jan 2008, Andrea Venturi wrote:
> 
>> Mike Isely wrote:
>>

...

> 
> Thanks.  I just skimmed it and it looks like exactly the sort of changes 
> that should be needed (additional data tables).  BTW you don't need to 
> patch pvrusb2.mod.c; that file is generated as part of the build 
> process.

yes. i knew it, but i forgot to polish the diff file when i made this 
first release.. anyway it's just a start.

> 
> 
>> i have to tell you i run a 2.6.23.9 kernel with v4l BUT without pvrusb2
>> in-kernel driver and using this latest isely.net driver:
>>
>>   http://www.isely.net/downloads/pvrusb2-mci-20071202.tar.bz2
>>
>> you can simply patch this driver with the attached file and install the module
>> on your kernel.
>>
>> BEWARE this patch CAN crash everything!! don't do it on a production machine!!
> 
> Well it's just table changes.  Are you getting an actual crash?

during my many "input swapping trials" for the s-video to work, i made 
some mistakes on the correct sequence to replace the (newly recompiled) 
pvrusb2 module without shutting down the device and i had a couple of 
lockups on the usb bus and some ops in dmesg related to the pvrusb2 
module (lsusb didn't come back, for example..)

when i did a correct sequence (like closing applications using the 
device, shutting down the device, removing the pvrusb2 module, removing 
the cable), i didn't get anymore module panic and usb lockups

so it seems there's something to be done WRT reliability on "corner 
cases". if i'll have more info about this topic i'll keep you posted.

>>
>> note the cx2341x config: it's still NTSC based in my opinion (720x480 30fps..)
> 
> There may be a problem in the cx2341x configuration.  However this 
> driver has been getting used in PAL type settings for quite a while and 
> if there were a timing set up issue here (60Hz vs 50Hz) then I think it 
> should have been biting people all along.

you are right.

when i link a STB with composite output, the device is automagically 
switching to correct (PAL) parameters.

it just seems that, on signal absence, you are just printing on the 
device info report, some NTSC default.

could it be?

>>
>> 1- BEWARE! sometime the kernel oops (don't know why! maybe it's still the
>> missing tuner but still configured?), i'm going to provide more details when
>> it occurs again
> 
> I'd like to hear more about this.

ok. when i'll have more info, i'll come back to you with details..

>> 2- the audio stream is too quick, no idea!
>> here you can see a sample broken stream (with my face!)
>>
>>   http://mhplab.cineca.tv/grabster-audio-broken.mpg
> 
> Audio is tricky.  This is one area that seems to change a lot among 
> various devices.  When using a cx25840, something else has to perform 
> the ADC function, i.e. sampling the analog waveform into a digital.  
> The Hauppauge 24xxx does this with a wm8775 which must be programmed 
> over I2C.  Another recently encountered device does this function with a 
> simple device needing no programming.  We need to identify what this 
> part is on your device so it can be set up correctly.

you are very right, as usual! :-)

on the back of the motherboard there is the "culprit": the AD converter 
Cirrus CS5340

   http://www.cirrus.com/en/pubs/proDatasheet/CS5340_F1.pdf

i don't get it if it's programmable so maybe it's a matter of xtal on 
the board. i can see three: the freq. seems 24.00, 27.00 and 28.6363

but, anyway, i really don't know how i can control this little beast to 
get good audio quality (i.e. the right sampling rate..)

> 
>>
>> 3- the svideo input is still slightly broken! with Luma2 i see the black and
>> white image BUT i rtried evey ChromaX combination (4..8) and i got only B&W or
>> flat green (!)
>>
>> do you have a hint about this?
> 
> This is another area that changes on different devices.  You've got the 
> right idea however.  Realize it might be possible that s-video luma 
> input could be physically shared with the composite input.  Aside from 
> continued guessing, there's following the PCB traces (which obviously 
> will be impractical on a multilayer board).  Another possibility is if 
> you could contact the manufacturer and get them to cough up the 
> registers and values they are setting for each input combination.  There 
> has been one case where that tactic worked.

Luma2 should be the right one for luminance, because i can see black and 
white only. (of course the composite input is empty on the device..

i tried to define other chroma input like CHROMA1 CHROMA2 and CHROMA3

but, if i use them i get on the dmesg log this message:

[15041.657615] cx25840 0-0044: 0x0220 is not a valid video input!
...
[............] cx25840 0-0044: 0x0320 is not a valid video input!
...
[............] cx25840 0-0044: 0x0120 is not a valid video input!

maybe it's only a guard inside the linux driver. i really don't know how 
it's working this cx25840.. i need to look to a datasheet

but maybe i can give a thorough look to the .inf file in the windows 
driver? tomorrow i'll try!


BTW, i have to correct a mistake in the previous port. i still need a 
firmware, actually i'm using one called v4l-cx2341x-enc.fw

/usr/lib/hotplug/firmware/v4l-cx2341x-enc.fw

$ md5sum /usr/lib/hotplug/firmware/v4l-cx2341x-enc.fw

   9b39b3d3bba1ce2da40f82ef0c50ef48


bye

andrea