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

Tue Jan 8 19:17:47 CST 2008

On Mon, 7 Jan 2008, Andrea Venturi wrote:

> Mike Isely wrote:
> 
> [...]
> 
> > 
> > The cx25840 has a number of possible inputs.  Some are composite and
> > some are paired in such a way to form an s-video input.  The wiring
> > and pairing depends on the surrounding circuits.  Obviously this is
> > different in your case.  The pvrusb2 driver assumes the wiring present
> > in the Hauppauge hardware of course and that assumption is probably
> > wrong here.  Very likely what's happening is that we need to change
> > this for your hardware.  Unfortunately there's going to be some
> > guesswork here and it's hard to explain concisely in an e-mail.
> > 
> > 
> 
> hi.
> 
> after the reworking of the driver with the new simplified routing scheme from
> Mike Isely (big kudos to him again for the overall care), i get back working
> on the Terratec Grabster av400
> 
> http://www.terratec.it/prodotti/video_editing/grabster_av400/board.JPG
> 
> and indeed now it's really easy to get it supported in the new environment!
> 
> in attach there's the first iteration of the patch.
> 
> it's not ready and polished but at least it's a start.

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.

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

> 
> 
> this way, when you attach the device, the Terratec Grabster should be
> recognized and start [*]. no firmware needed..
> 
> then you should switch to the composite input with this command (it starts on
> input tv as default, but we don't have a tuner, i put it on the right
> composite input anyway!):
> 
>   echo composite > /sys/class/pvrusb2/unit-a/ctl_input/cur_val
> 
> maybe we could provide a different default input on module loading (on a case
> by case based on the card type?)

That is a good idea.  I will implement something for this.

When I started work to isolate out device specific changes, I knew then 
that I probably wasn't going to find "everything" on the first pass.  Or 
the second pass, or the third pass...  The device table is set up so 
that it should be relatively painless to implement additional attributes 
as we go forward.  This suggestion is a good one.

> 
> 
> andrea at nb-venturi:/sys/class/pvrusb2/unit-a$ cat debuginfo
> Driver state info:
> driver: <ok> <init> <connected>
> pipeline: <idle> <configok>
> worker: <decode:quiescent> <encode:stop> <encode:wait> <usb:stop>
> state: ready
> Attached I2C modules:
> cx25840 @ 0x44 (handler: pvrusb2-cx2584x-v4l) [v4l2_standard v4l2_audiomode
> v4l2_bcsh v4l2_volume v4l2_freq v4l2_size v4l2_log]
> 
> 
> in dmesg you'll see:
> 
> ...
> [ 2643.352046] pvrusb2: =================  START STATUS CARD #0
> =================
> [ 2643.354794] cx25840 0-0044: Video signal:              present
> [ 2643.354974] cx25840 0-0044: Detected format:           PAL-BDGHI
> [ 2643.355139] cx25840 0-0044: Specified standard:        PAL-BDGHI
> [ 2643.355290] cx25840 0-0044: Specified video input:     Composite 1
> [ 2643.355516] cx25840 0-0044: Specified audioclock freq: 48000 Hz
> [ 2643.355667] pvrusb2: cx2341x config:
> [ 2643.355809] pvrusb2: Stream: MPEG-2 Program Stream
> [ 2643.355962] pvrusb2: VBI Format: No VBI
> [ 2643.356104] pvrusb2: Video:  720x480, 30 fps
> [ 2643.356247] pvrusb2: Video:  MPEG-2, 4x3, Variable Bitrate, 6000000, Peak
> 8000000
> [ 2643.356413] pvrusb2: Video:  GOP Size 12, 2 B-Frames, GOP Closure
> [ 2643.356562] pvrusb2: Audio:  48 kHz, Layer II, 224 kbps, Stereo, No
> Emphasis, No CRC
> [ 2643.356723] pvrusb2: Spatial Filter:  Manual, Luma 1D Horizontal, Chroma 1D
> Horizontal, 0
> [ 2643.356874] pvrusb2: Temporal Filter: Manual, 8
> [ 2643.357019] pvrusb2: Median Filter:   Off, Luma [0, 255], Chroma [0, 255]
> [ 2643.357168] pvrusb2_a driver: <ok> <init> <connected>
> [ 2643.357313] pvrusb2_a pipeline: <idle> <configok>
> [ 2643.357456] pvrusb2_a worker: <decode:quiescent> <encode:stop>
> <encode:wait> <usb:stop>
> [ 2643.357606] pvrusb2_a state: ready
> [ 2643.357789] pvrusb2: ==================  END STATUS CARD #0
> ==================
> 
> 
> 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.

> 
> and you should get a color program stream with:
> 
>   cat /dev/video0 > /tmp/prova.mpg
> 
> BUT i still have three glitches:
> 
> 
> 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.

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

> 
> this what mplayer tells me about it:
> 
> ==========================================================================
> Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
> dec_audio: Allocating 4608 + 65536 = 70144 bytes for output buffer.
> mp3lib: using SSE optimized decore!
> MP3lib: init layer2&3 finished, tables done
> MPEG 1.0, Layer II, 48000 Hz 224 kbit Stereo, BPF: 672
> Channels: 2, copyright: No, original: No, CRC: No, emphasis: 0
> AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000->192000)
> Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
> ==========================================================================
> 
> 
> maybe i need to change the cx2341x config; how can i do it using the
> /sys/class/pvrusb2/*/ctl_ controls?

The audio sampling / digitization happens upstream of the cx23416; my 
experience is that the cx23416 should be fine but we need to figure out 
what is digitizing your audio.

> 
> i did find a way to change audio sampling rate (ctl_srate to 44.1KHz) but the
> audio then was completely missing on the stream..

See above...

> 
> 
> what about change the video frame rate.. from 30 to 25fps? don't see a fps
> control..

The frame rate is a function of the chosen video standard.  The driver 
should be correctly setting everything to match.  So I'm not sure what 
is going on here.

> 
> 
> 3- the svideo input is still slightly broken! with Luma2 i see the black and
> white image BUT i tried 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.

> 
> 
> let me know if it works more or less for you grabster owner too..

Being in the USA, I don't have one of these devices so I can't test.  
(And also I'm NTSC here so any testing I could do would probably be of 
limited value...)

  -Mike

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |