Mailing List Archive

On Mon, 2009-07-06 at 15:52 +0530, Ravi A wrote:
> Sorry, this message did not get through to the list due to attachments
> (Please see original below).
> Images are online -
> http://www.flickr.com/photos/26209946@N00/3693087045/
> http://www.flickr.com/photos/26209946@N00/3693087051/
>
>
> ---------- Forwarded message ----------
> From: Ravi A <asvravi@gmail.com>
> Date: Mon, Jul 6, 2009 at 2:21 AM
> Subject: Re: [UNKNOWN IVTV CARD] (cx23416) AverMedia M113-C
> To: ivtv-devel@ivtvdriver.org
> Cc: asvravi@gmail.com
>
>
> Hi Andy,
>
> Thanks a lot for your help, I really appreciate this.
>
> Yes, this card seems to use the same board as the other one you are
> working on. I bought this card in Taiwan.
>
> Latest update - As a temporary hack, I forced the card detection to
> use AverMedia PVR 150 Plus (after seeing the hardware seems to match
> on bttv gallery, except for no FM in this one) using the following in
> modprobe -
> options ivtv cardtype=23
> options ivtv tunertype=0
> After this the Composite and S-Video inputs started working and
> picture quality seems pretty good! Tuner picture seems choppy and
> noisy. Audio still seems to be missing completely (checked in mplayer
> and mthtv both), but I need to check if something else is causing that
> in my setup.
>
> The details you asked for -
>
> Tuner -
> PTI-5NF05N
> P4L 13S
> PARTSNIC
> (This seems to be similar to the one on AverMedia PVR150)
>
> Other chips -
> CX23146-12
> CX25841-23
> ESMT M12L64322A
> WM8739
> 74HC4052D
>
> Crystal oscillators -
> H28.636
> V27.000 KDSH5A
>
> No other major chips on the board, just what seem to be some voltage regulators.
>
> I have attached hi-res pictures of the card here.

Ravi,

I have made two patches here:

http://linuxtv.org/hg/~awalls/ivtv

The first patch adds a new entry for the Partnic PTI-5NF05 tuner in the
tuner-simple module.

The second patch modifies the AVer PVR-150 card entry to add your AVerTV
M113 variant with a Partsnic tuner. (Apparently the AVerMedia AVerTV
M113 variants fall into 2 groups: those with Philips tuners and those
with Partsnic (Daewoo) tuners.)

Please test.


Hans,

If you have time, please check the ivtv-cards.c entry that I modified.
The GPIO settings looked like guesses that were never verified. I
replaced them with what I'm prettry sure is right, but I obviously don't
want to break the AVer PVR-150 (another M113 variant) operation.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Tue, Jul 7, 2009 at 7:00 AM, Andy Walls<awalls@radix.net> wrote:
> On Mon, 2009-07-06 at 15:52 +0530, Ravi A wrote:
>> Sorry, this message did not get through to the list due to attachments
>> (Please see original below).
>> Images are online -
>> http://www.flickr.com/photos/26209946@N00/3693087045/
>> http://www.flickr.com/photos/26209946@N00/3693087051/
>>
>>
>> ---------- Forwarded message ----------
>> From: Ravi A <asvravi@gmail.com>
>> Date: Mon, Jul 6, 2009 at 2:21 AM
>> Subject: Re: [UNKNOWN IVTV CARD] (cx23416) AverMedia M113-C
>> To: ivtv-devel@ivtvdriver.org
>> Cc: asvravi@gmail.com
>>
>>
>> Hi Andy,
>>
>> Thanks a lot for your help, I really appreciate this.
>>
>> Yes, this card seems to use the same board as the other one you are
>> working on. I bought this card in Taiwan.
>>
>> Latest update - As a temporary hack, I forced the card detection to
>> use AverMedia PVR 150 Plus (after seeing the hardware seems to match
>> on bttv gallery, except for no FM in this one) using the following in
>> modprobe -
>> options ivtv cardtype=23
>> options ivtv tunertype=0
>> After this the Composite and S-Video inputs started working and
>> picture quality seems pretty good! Tuner picture seems choppy and
>> noisy. Audio still seems to be missing completely (checked in mplayer
>> and mthtv both), but I need to check if something else is causing that
>> in my setup.
>>
>> The details you asked for -
>>
>> Tuner -
>> PTI-5NF05N
>> P4L 13S
>> PARTSNIC
>> (This seems to be similar to the one on AverMedia PVR150)
>>
>> Other chips -
>> CX23146-12
>> CX25841-23
>> ESMT M12L64322A
>> WM8739
>> 74HC4052D
>>
>> Crystal oscillators -
>> H28.636
>> V27.000 KDSH5A
>>
>> No other major chips on the board, just what seem to be some voltage regulators.
>>
>> I have attached hi-res pictures of the card here.
>
> Ravi,
>
> I have made two patches here:
>
>        http://linuxtv.org/hg/~awalls/ivtv
>
> The first patch adds a new entry for the Partnic PTI-5NF05 tuner in the
> tuner-simple module.
>
> The second patch modifies the AVer PVR-150 card entry to add your AVerTV
> M113 variant with a Partsnic tuner.  (Apparently the AVerMedia AVerTV
> M113 variants fall into 2 groups: those with Philips tuners and those
> with Partsnic (Daewoo) tuners.)
>
> Please test.
>
>
> Hans,
>
> If you have time, please check the ivtv-cards.c entry that I modified.
> The GPIO settings looked like guesses that were never verified.  I
> replaced them with what I'm prettry sure is right, but I obviously don't
> want to break the AVer PVR-150 (another M113 variant) operation.
>
> Regards,
> Andy
>
>

Hi Andy,

I compiled and installed this version and it worked like a charm! Thanks a lot.

- Recognizes the correct card, chips and tuner (dmesg) and no errors
in initialization

- Checked composite and tuner inputs with /dev/video0, both are functional

- Composite input gives decent picture quality (although there seen to
be some minor artifacts at edges of red/yellow in all players - but
maybe this is the best that can be expected from this capture card?)

- Tuner input - can get a picture, but has color artifacts, even after
fine-tuning frequency with ivctl. Are there any settings for color
sub-frequency etc I need to tune? I am using India Cable, so the
frequencies and sub-carriers may be different. In any case I do not
plan to use the tuner input, but can test and report back on any
experiments if needed.

- S-video input - not checked yet, will do this later after getting an
S-video source

- Audio - it came up briefly, but missing again now. I may need to
check all the other system settings for this one.

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Wed, 2009-07-08 at 04:12 +0530, Ravi A wrote:
> On Tue, Jul 7, 2009 at 7:00 AM, Andy Walls<awalls@radix.net> wrote:
> > On Mon, 2009-07-06 at 15:52 +0530, Ravi A wrote:
> >
> > Ravi,
> >
> > I have made two patches here:
> >
> > http://linuxtv.org/hg/~awalls/ivtv
> >
> > The first patch adds a new entry for the Partnic PTI-5NF05 tuner in the
> > tuner-simple module.
> >
> > The second patch modifies the AVer PVR-150 card entry to add your AVerTV
> > M113 variant with a Partsnic tuner. (Apparently the AVerMedia AVerTV
> > M113 variants fall into 2 groups: those with Philips tuners and those
> > with Partsnic (Daewoo) tuners.)
> >
> > Please test.
> >
> >
>
> Hi Andy,
>
> I compiled and installed this version and it worked like a charm! Thanks a lot.
>
> - Recognizes the correct card, chips and tuner (dmesg) and no errors
> in initialization
>
> - Checked composite and tuner inputs with /dev/video0, both are functional

OK, good. I' suspect I may have the chroma input for S-Video wrong.
Let me know if S-Video is only in black and white.

> - Composite input gives decent picture quality (although there seen to
> be some minor artifacts at edges of red/yellow in all players - but
> maybe this is the best that can be expected from this capture card?)

Hmmm. There may be something that can be tweaked in the cx25840 module.
That modules gets the most testing against the CX25843 and the CX25841
is slightly different.

Also, after setting the input to composite, you could try using v4l2-ctl
to set the video standard explicitly:

$ v4l2-ctl -d /dev/video0 -i2
Video input set to 2 (Composite 1)
$ v4l2-ctl -d /dev/video0 -s pal-B
Standard set to 00000007
$ v4l2-ctl -d /dev/video0 -S
Video Standard = 0x00000007
PAL-B/B1/G


> - Tuner input - can get a picture, but has color artifacts, even after
> fine-tuning frequency with ivctl. Are there any settings for color
> sub-frequency etc I need to tune? I am using India Cable, so the
> frequencies and sub-carriers may be different. In any case I do not
> plan to use the tuner input, but can test and report back on any
> experiments if needed.

The Partsnic PTI-5NF05 tuner is an NTSC-M tuner. India is a PAL-B/G
country. I'm surprised you have a picture with the tuner at all.

I don't know what chips are in the tuner. I assume an Infineon TUA6030
(or clone ) mixer/oscillator chip is the first stage and some othe demod
chip is the second stage. If I knew the chips in the tuner (dmesg
output?) I might be able to tweak things a little, but trying to force a
NTSC-M tuner to do PAL-B/G is never going to work.



> - S-video input - not checked yet, will do this later after getting an
> S-video source

I may have gotten S-Video color wrong. You'll get Luma (black and
white), but maybe not chroma (color). Let me know.

Also don't forget to set the video standard for the incoming signal.



> - Audio - it came up briefly, but missing again now. I may need to
> check all the other system settings for this one.

Hmmm. You may want to try and capture the MPEG stream to a file:

$ cat /dev/video0 > foo.mpg

and then playback the file on a machine with a known good sound setup to
make sure the CX25841/CX23416 is capturing the sound properly.

Also, set the driver to use a 48 ksps audio sample rate and not 32 ksps.
The cx25840 module drives the CX2584x chip's audio PLL out of its valid
operating range for 32 ksps audio. Most newer CX25843 chips don't seem
to care being told to operate too slow, but the audio PLL in some
CX2584x cores stop oscillating under that condition.

Regards,
Andy


> Regards
> Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Wed, Jul 8, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
>>
>> - Checked composite and tuner inputs with /dev/video0, both are functional
>
> OK, good.  I' suspect I may have the chroma input for S-Video wrong.
> Let me know if S-Video is only in black and white.

Indeed, S-video is only in black and white.

>
>> - Composite input gives decent picture quality (although there seen to
>> be some minor artifacts at edges of red/yellow in all players - but
>> maybe this is the best that can be expected from this capture card?)
>
> Hmmm.  There may be something that can be tweaked in the cx25840 module.
> That modules gets the most testing against the CX25843 and the CX25841
> is slightly different.
>
> Also, after setting the input to composite, you could try using v4l2-ctl
> to set the video standard explicitly:
>
> $ v4l2-ctl -d /dev/video0 -i2
> Video input set to 2 (Composite 1)
> $ v4l2-ctl -d /dev/video0 -s pal-B
> Standard set to 00000007
> $ v4l2-ctl -d /dev/video0 -S
> Video Standard = 0x00000007
>        PAL-B/B1/G

I tried this, but the picture did not improve. I tried all the PAL and
even a few other standards too.
PS: v4l2-ctl did not recognize the pal-B command argument, it kept
setting pal-H. I had to use numeric argument. A numeric argument of 6
sets the standard to 7 (one higher).

posted some pics and a video clip here -
snapshot-svideo - http://www.flickr.com/photos/26209946@N00/3704069849/
snapshot-composite - http://www.flickr.com/photos/26209946@N00/3704069841/
video-composite - http://www.flickr.com/photos/26209946@N00/3704069859/

(Can notice some dot artifacts in red/yellow region borders in all of
the above. These are not present in direct source connection to TV)


>
>
>> - Tuner input - can get a picture, but has color artifacts, even after
>> fine-tuning frequency with ivctl. Are there any settings for color
>> sub-frequency etc I need to tune? I am using India Cable, so the
>> frequencies and sub-carriers may be different. In any case I do not
>> plan to use the tuner input, but can test and report back on any
>> experiments if needed.
>
> The Partsnic PTI-5NF05 tuner is an NTSC-M tuner.  India is a PAL-B/G
> country.  I'm surprised you have a picture with the tuner at all.


The box in which the card came advertises PAL/NTSC/SECAM with a globe
icon! So I assumed it supported all standards. And yes the picture
looks too reasonable to be coming from a mismatched standard (sync and
size is perfectly OK, just the color information seems haywire/noisy
or totally missing depending on the actual fine-tuned frequency
setting)


>
> I don't know what chips are in the tuner.  I assume an Infineon TUA6030
> (or clone ) mixer/oscillator chip is the first stage and some othe demod
> chip is the second stage.  If I knew the chips in the tuner (dmesg
> output?) I might be able to tweak things a little, but trying to force a
> NTSC-M tuner to do PAL-B/G is never going to work.
>

posted a picture of the tuner insides -
http://www.flickr.com/photos/26209946@N00/3704069839/

The only IC I could find on the top side (in-line pin package in the
5th compartment from left) is marked -
EPCOS M1865D
1847 1XS6
Rest all seems to be just passives. There may be other chips on the
bottom side, but that would need de-soldering the can to look - I can
attempt this sometime if you think it would be useful.

dmesg output -

[ 22.481423] Linux video capture interface: v2.00
[ 22.527503] ivtv: Start initialization, version 1.4.1
[ 22.527556] ivtv0: Initializing card 0
[ 22.527558] ivtv0: Autodetected AVerMedia PVR-150 Plus / AVerTV
M113 Partsnic (Daewoo) Tuner card (cx23416 based)
[ 22.527644] ivtv 0000:01:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[ 22.527651] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
[ 22.539677] cx25840 0-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
[ 22.557064] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
[ 22.574919] wm8739 0-001a: chip found @ 0x34 (ivtv i2c driver #0)
[ 22.669312] tuner-simple 0-0061: creating new instance
[ 22.669314] tuner-simple 0-0061: type set to 81 (Partsnic (Daewoo) PTI-5NF05)
[ 22.670506] ivtv0: Registered device video0 for encoder MPG (4096 kB)
[ 22.670521] ivtv0: Registered device video32 for encoder YUV (2048 kB)
[ 22.670535] ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
[ 22.670549] ivtv0: Registered device video24 for encoder PCM (320 kB)
[ 22.670565] ivtv0: Registered device radio0 for encoder radio
[ 22.670566] ivtv0: Initialized card: AVerMedia PVR-150 Plus /
AVerTV M113 Partsnic (Daewoo) Tuner
[ 22.670578] ivtv: End initialization

[ 30.040086] ivtv 0000:01:00.0: firmware: requesting v4l-cx2341x-enc.fw
[ 30.087476] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
[ 30.284215] ivtv0: Encoder revision: 0x02060039
[ 30.301111] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
[ 33.737874] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)


>
>
>> - S-video input - not checked yet, will do this later after getting an
>> S-video source
>
> I may have gotten S-Video color wrong.  You'll get Luma (black and
> white), but maybe not chroma (color).  Let me know.
>
> Also don't forget to set the video standard for the incoming signal.
>
>
>
>> - Audio - it came up briefly, but missing again now. I may need to
>> check all the other system settings for this one.
>
> Hmmm.  You may want to try and capture the MPEG stream to a file:
>
>  $ cat /dev/video0 > foo.mpg
>
> and then playback the file on a machine with a known good sound setup to
> make sure the CX25841/CX23416 is capturing the sound properly.
>
> Also, set the driver to use a 48 ksps audio sample rate and not 32 ksps.
> The cx25840 module drives the CX2584x chip's audio PLL out of its valid
> operating range for 32 ksps audio.  Most newer CX25843 chips don't seem
> to care being told to operate too slow, but the audio PLL in some
> CX2584x cores stop oscillating under that condition.
>

I captured it using vlc and played back on a windows laptop :) The
sound was too low and seemed very choppy (maybe not unlike that due to
a PLL operating at the edge of its hold range!). You can notice it in
the video clip I linked above.
Although I did not explicitly set the sample rate, mplayer reported
48ksps for the captured stream.

Thanks!
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-07-09 at 23:04 +0530, Ravi A wrote:
> On Wed, Jul 8, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
> >>
> >> - Checked composite and tuner inputs with /dev/video0, both are functional
> >
> > OK, good. I' suspect I may have the chroma input for S-Video wrong.
> > Let me know if S-Video is only in black and white.
>
> Indeed, S-video is only in black and white.
>

Ravi,

I've pushed a patch to

http://linuxtv.org/hg/~awalls/ivtv

to fix SVideo chroma for the M113 boards.


> >> - Composite input gives decent picture quality (although there seen to
> >> be some minor artifacts at edges of red/yellow in all players - but
> >> maybe this is the best that can be expected from this capture card?)
> >
> > Hmmm. There may be something that can be tweaked in the cx25840 module.
> > That modules gets the most testing against the CX25843 and the CX25841
> > is slightly different.
> >
> > Also, after setting the input to composite, you could try using v4l2-ctl
> > to set the video standard explicitly:
> >
> > $ v4l2-ctl -d /dev/video0 -i2
> > Video input set to 2 (Composite 1)
> > $ v4l2-ctl -d /dev/video0 -s pal-B
> > Standard set to 00000007
> > $ v4l2-ctl -d /dev/video0 -S
> > Video Standard = 0x00000007
> > PAL-B/B1/G
>
> I tried this, but the picture did not improve. I tried all the PAL and
> even a few other standards too.
> PS: v4l2-ctl did not recognize the pal-B command argument, it kept
> setting pal-H. I had to use numeric argument. A numeric argument of 6
> sets the standard to 7 (one higher).

Hmm. That's odd. Probably some mismatch between the latest v4l-dvb
drivers and the v4l2-ctl you have. Oh well, as long as

$ v4l2-ctl -d /dev/video0 --log-status

shows you what you expect.



> posted some pics and a video clip here -
> snapshot-svideo - http://www.flickr.com/photos/26209946@N00/3704069849/
> snapshot-composite - http://www.flickr.com/photos/26209946@N00/3704069841/
> video-composite - http://www.flickr.com/photos/26209946@N00/3704069859/
>
> (Can notice some dot artifacts in red/yellow region borders in all of
> the above. These are not present in direct source connection to TV)

I see them in the color snapshot. (I can't see the flash video as I
don't have a flash player). The artifacts look, at least in part, due
to the MPEG compression that the CX23416 is performing on the video. If
you notice, there seems to be some subtle artifacts around the white
lettering and the black trim of the tools. The red '@' does look bad.

You should use v4l2-ctl to list the controls (with menus) and start
playing with the MPEG settings and filters. I suspect if you don't
perform much compression at all, the artifacts will diminish.

There are some video processing controls in the CX25841 (a comb filter,
white crush, chroma coring, etc) but they are not easily manipulated
with user tools IIRC.




> >> - Tuner input - can get a picture, but has color artifacts, even after
> >> fine-tuning frequency with ivctl. Are there any settings for color
> >> sub-frequency etc I need to tune? I am using India Cable, so the
> >> frequencies and sub-carriers may be different. In any case I do not
> >> plan to use the tuner input, but can test and report back on any
> >> experiments if needed.
> >
> > The Partsnic PTI-5NF05 tuner is an NTSC-M tuner. India is a PAL-B/G
> > country. I'm surprised you have a picture with the tuner at all.
>
>
> The box in which the card came advertises PAL/NTSC/SECAM with a globe
> icon! So I assumed it supported all standards. And yes the picture
> looks too reasonable to be coming from a mismatched standard (sync and
> size is perfectly OK, just the color information seems haywire/noisy
> or totally missing depending on the actual fine-tuned frequency
> setting)
>
>
> >
> > I don't know what chips are in the tuner. I assume an Infineon TUA6030
> > (or clone ) mixer/oscillator chip is the first stage and some othe demod
> > chip is the second stage. If I knew the chips in the tuner (dmesg
> > output?) I might be able to tweak things a little, but trying to force a
> > NTSC-M tuner to do PAL-B/G is never going to work.
> >
>
> posted a picture of the tuner insides -
> http://www.flickr.com/photos/26209946@N00/3704069839/
>
> The only IC I could find on the top side (in-line pin package in the
> 5th compartment from left) is marked -
> EPCOS M1865D
> 1847 1XS6

That's likely a SAW filter between the first mixer output and the IF
demodulator.


> Rest all seems to be just passives. There may be other chips on the
> bottom side, but that would need de-soldering the can to look - I can
> attempt this sometime if you think it would be useful.

There's really no need. According to the datasheet here:

http://www.datasheet4u.com/download.php?id=522531
http://www.datasheet4u.com/html/P/T/I/PTI-5NF05_ETC.pdf.html

The assembly is obviously an NTSC tuner.

NTSC and PAL have different bandwidths and chroma subcarrier
frequencies. The tuner assembly is going to have filters and passive
components appropriate for NTSC.

Check the *.inf file that comes with the Windows driver for your card
(Subsystem ID C0341461) and see if it alludes to the tuner type.


> dmesg output -
>
> [ 22.481423] Linux video capture interface: v2.00
> [ 22.527503] ivtv: Start initialization, version 1.4.1
> [ 22.527556] ivtv0: Initializing card 0
> [ 22.527558] ivtv0: Autodetected AVerMedia PVR-150 Plus / AVerTV
> M113 Partsnic (Daewoo) Tuner card (cx23416 based)
> [ 22.527644] ivtv 0000:01:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
> [ 22.527651] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> [ 22.539677] cx25840 0-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
> [ 22.557064] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> [ 22.574919] wm8739 0-001a: chip found @ 0x34 (ivtv i2c driver #0)
> [ 22.669312] tuner-simple 0-0061: creating new instance
> [ 22.669314] tuner-simple 0-0061: type set to 81 (Partsnic (Daewoo) PTI-5NF05)

Hmmm. No programmable demodulator apparently(?).


> [ 22.670506] ivtv0: Registered device video0 for encoder MPG (4096 kB)
> [ 22.670521] ivtv0: Registered device video32 for encoder YUV (2048 kB)
> [ 22.670535] ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> [ 22.670549] ivtv0: Registered device video24 for encoder PCM (320 kB)
> [ 22.670565] ivtv0: Registered device radio0 for encoder radio
> [ 22.670566] ivtv0: Initialized card: AVerMedia PVR-150 Plus /
> AVerTV M113 Partsnic (Daewoo) Tuner
> [ 22.670578] ivtv: End initialization
>
> [ 30.040086] ivtv 0000:01:00.0: firmware: requesting v4l-cx2341x-enc.fw
> [ 30.087476] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> [ 30.284215] ivtv0: Encoder revision: 0x02060039
> [ 30.301111] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
> [ 33.737874] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
>
>
> >
> >
> >> - S-video input - not checked yet, will do this later after getting an
> >> S-video source
> >
> > I may have gotten S-Video color wrong. You'll get Luma (black and
> > white), but maybe not chroma (color). Let me know.
> >
> > Also don't forget to set the video standard for the incoming signal.
> >
> >
> >
> >> - Audio - it came up briefly, but missing again now. I may need to
> >> check all the other system settings for this one.
> >
> > Hmmm. You may want to try and capture the MPEG stream to a file:
> >
> > $ cat /dev/video0 > foo.mpg
> >
> > and then playback the file on a machine with a known good sound setup to
> > make sure the CX25841/CX23416 is capturing the sound properly.
> >
> > Also, set the driver to use a 48 ksps audio sample rate and not 32 ksps.
> > The cx25840 module drives the CX2584x chip's audio PLL out of its valid
> > operating range for 32 ksps audio. Most newer CX25843 chips don't seem
> > to care being told to operate too slow, but the audio PLL in some
> > CX2584x cores stop oscillating under that condition.
> >
>
> I captured it using vlc and played back on a windows laptop :) The
> sound was too low and seemed very choppy (maybe not unlike that due to
> a PLL operating at the edge of its hold range!). You can notice it in
> the video clip I linked above.
> Although I did not explicitly set the sample rate, mplayer reported
> 48ksps for the captured stream.

48 ksps is the default. VLC might change it for the capture. When VLC,
or any other app, is capturing, you can use v4l2-ctl -d /dev/video0
--log-status to see how the capture is configured. (v4l2 device nodes
are multiple open.)

I'll look into what I might be able to do in the CX25840 driver about
fixing the PLL clocks.

The volume is controllable with the controls available with v4l2-ctl.

Regards,
Andy

>
> Thanks!
> Ravi
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Hi Andy,

I was able to get some experimentation done yesterday and today. Below
inline are my responses -

>>
>
> Ravi,
>
> I've pushed a patch to
>
> http://linuxtv.org/hg/~awalls/ivtv
>
> to fix SVideo chroma for the M113 boards.
>
>

S-Video is OK now with this patch!
In fact, the red/yellow artifacts seem significantly lesser in S-video
connection, almost same quality now as a direct connection to TV.
Strangely though, the original source of this video is still Composite
from STB, I just routed it through a DVD recorder to get S-Video out
to connect to the card. So it seems only the Composite input of the
card has the artifacts issue. I plan to check the quality of the
cabling tomorrow to eliminate any cable bandwidth issues.


>
>> posted some pics and a video clip here -
>> snapshot-svideo - http://www.flickr.com/photos/26209946@N00/3704069849/
>> snapshot-composite - http://www.flickr.com/photos/26209946@N00/3704069841/
>> video-composite - http://www.flickr.com/photos/26209946@N00/3704069859/
>>
>> (Can notice some dot artifacts in red/yellow region borders in all of
>> the above. These are not present in direct source connection to TV)
>
> I see them in the color snapshot.  (I can't see the flash video as I
> don't have a flash player).  The artifacts look, at least in part, due
> to the MPEG compression that the CX23416 is performing on the video.  If
> you notice, there seems to be some subtle artifacts around the white
> lettering and the black trim of the tools.  The red '@' does look bad.
>
> You should use v4l2-ctl to list the controls (with menus) and start
> playing with the MPEG settings and filters.  I suspect if you don't
> perform much compression at all, the artifacts will diminish.
>

I experimented with all the bitrate/filter options but none helped for
this particular artifacts issue on Composite input. Maybe the
artifacts in the snapshot I attached are different from the red/yellow
artifacts that are seen in the video I attached (I will try to upload
it somewhere where it does not convert to flash format). The only
thing that seemed a help a bit was to use De-interlacing (Blend mode)
in VLC. Other de-interlacing modes were not helping. So could this
issue be related to swapped odd/even fields etc? I will check later to
find a way to swap the fields.

>
> The assembly is obviously an NTSC tuner.
>
> NTSC and PAL have different bandwidths and chroma subcarrier
> frequencies.  The tuner assembly is going to have filters and passive
> components appropriate for NTSC.
>
> Check the *.inf file that comes with the Windows driver for your card
> (Subsystem ID C0341461) and see if it alludes to the tuner type.
>

It indeed seems to be NTSC tuner - Partsnic, NTSC, without FM.
I will try and obtain an NTSC source to check the tuner picture tomorrow.


> 48 ksps is the default.  VLC might change it for the capture.  When VLC,
> or any other app, is capturing, you can use v4l2-ctl -d /dev/video0
> --log-status to see how the capture is configured.  (v4l2 device nodes
> are multiple open.)
>
> I'll look into what I might be able to do in the CX25840 driver about
> fixing the PLL clocks.
>
> The volume is controllable with the controls available with v4l2-ctl.
>

I checked with this and it is in 48ksps all the time.
After the latest patch the Audio too started working again for all the
inputs. But since it worked intermittently in the past, I will observe
it for a longer period of time.

Also another point - I found a delay of about 1sec in the MPEG video
stream compared to realtime, even with mplayer cache set to the
minimum where it would still work (128). Is this related to the MPEG
buffers in the card, and if so, is that controlled from this driver?
Is this parameter something that needs to be (or can be) tuned in this
driver?

Thanks a lot for all your help!

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-07-09 at 20:32 -0400, Andy Walls wrote:
> On Thu, 2009-07-09 at 23:04 +0530, Ravi A wrote:
> > On Wed, Jul 8, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:



> > >> - Audio - it came up briefly, but missing again now. I may need to
> > >> check all the other system settings for this one.
> > >
> > > Hmmm. You may want to try and capture the MPEG stream to a file:
> > >
> > > $ cat /dev/video0 > foo.mpg
> > >
> > > and then playback the file on a machine with a known good sound setup to
> > > make sure the CX25841/CX23416 is capturing the sound properly.
> > >
> > > Also, set the driver to use a 48 ksps audio sample rate and not 32 ksps.
> > > The cx25840 module drives the CX2584x chip's audio PLL out of its valid
> > > operating range for 32 ksps audio. Most newer CX25843 chips don't seem
> > > to care being told to operate too slow, but the audio PLL in some
> > > CX2584x cores stop oscillating under that condition.
> > >
> >
> > I captured it using vlc and played back on a windows laptop :) The
> > sound was too low and seemed very choppy (maybe not unlike that due to
> > a PLL operating at the edge of its hold range!). You can notice it in
> > the video clip I linked above.
> > Although I did not explicitly set the sample rate, mplayer reported
> > 48ksps for the captured stream.
>
> 48 ksps is the default. VLC might change it for the capture. When VLC,
> or any other app, is capturing, you can use v4l2-ctl -d /dev/video0
> --log-status to see how the capture is configured. (v4l2 device nodes
> are multiple open.)
>
> I'll look into what I might be able to do in the CX25840 driver about
> fixing the PLL clocks.

Ravi,

I have added a change here:

http://linuxtv.org/hg/~awalls/ivtv

to the cx25840 module. The change ensures that the Video and Aux PLLs
for CX2584x chips run close to 400 MHz, the center frequency of the
VCOs. The change is essentially what the cx18 driver does for it's
integrated A/V core.

Please see if you get reliable audio with the CX25841 on your board with
this change.

Regards,
Andy

> The volume is controllable with the controls available with v4l2-ctl.
>
> Regards,
> Andy
>
> >
> > Thanks!
> > Ravi
> >



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, 2009-07-12 at 17:36 +0530, Ravi A wrote:
> On Sat, Jul 11, 2009 at 9:43 PM, Andy Walls<awalls@radix.net> wrote:
>
> > Ravi,
> >
> > I have added a change here:
> >
> > http://linuxtv.org/hg/~awalls/ivtv
> >
> > to the cx25840 module. The change ensures that the Video and Aux PLLs
> > for CX2584x chips run close to 400 MHz, the center frequency of the
> > VCOs. The change is essentially what the cx18 driver does for it's
> > integrated A/V core.
> >
> > Please see if you get reliable audio with the CX25841 on your board with
> > this change.
> >
> > Regards,
> > Andy
> >
>
> Hi Andy,
>
> The audio still does not work consistently with this version. Let me
> know if there is any way I can check whether the new settings got
> applied.

Well, if you conpiled the modules with the CONFIG_ADV_DEBUG (?) option,
then you can use v4l2-dbg to look at the registers of the chips.
Something like this will show you the change is in effect:

$ su - root

# v4l2-dbg -d /dev/video0 -S
host0: cx23416 revision 0x00000000
i2c 0x1b: wm8775 revision 0x00000000
i2c 0x44: cx25843 revision 0x00008433

# v4l2-dbg -d /dev/video0 -c cx25840 --list-registers=min=0x110,max=0x113
ioctl: VIDIOC_DBG_G_REGISTER

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000110: 0c 74 76 01
^^^^^^^^^^^
|
Indicator of the change, when set to line-in at 48 ksps.



Here's my guess at the audio processing chain on your card:


+----------+ +---------------+
| Sel0 |<--------------------------------------| GPIO14 |
| Sel1 |<--------------------------------------| GPIO15 |
| | | |
(FM AF L)---->| 74HC4052 | | |
(FM AF R)---->| | +----------------+------------|I2C Data & CLK |
| Dual 4:1 | V V | |
| Mux | +------+ +--------------+ | |
Line-in L --->| | |WM8739| | CX25841 | | CX23416 |
Line-in R --->| |---->|Analog|----->|I2S Data In | | |
| |---->|to I2S|------|I2S Clock | | |
White Conn?-->| | |Audio | | I2S Data Out |--->|I2S Data In |
| | +------+ | I2S Clock |----|I2S Clock |
+----------+ | | | |
Tuner SIF ---------------------------------->|SIF In | +---------------+
| |
+--------------+


I realize your card doesn't have FM radio audio, but variants of it with
the same PCB do have FM.

The above picutre is just my guess. Without having the card in hand,
it's hard to actaully trace the wiring. So let's look at where thing
could be going wrong for Line-in audio:


1. I could be setting the 74HC4052 dual 4:1 multiplexer wrong. The
datasheet is here:

http://www.datasheetcatalog.com/datasheets_pdf/7/4/H/C/74HC4052.shtml

So if you could trace how line-in L & R run over to the chip, that would
eliminate an unknown.

2. I could be using the wrong GPIO pins from the CX23416 for controlling
the 74HC4052 mux. Floating GPIO pins for driving the mux selection
would explain why sometimes audio works and sometimes doesn't. The best
thing to do is to trace the selection inputs from the 74HC4052 back to
the CX23416's BGA and figure out which balls in the grid are driving
those lines. An alternative would be to begin experimenting with pairs
of GPIO pins in the ivtv-cards.c entry for your card, or use ivtv-ctl to
manipulate GPIO pins interactively to see when audio works (or you
change the state of the select pins on the 74HC4052 mux.


3. The WM8739 does actually have a volume control internally, that we
are not explicitly setting - I'm using whatever the WM8739 module does
by default. v4l2-dbg could be used to set the WM8739 volume control
registers manually to see if that makes audio work.

The datasheet is here:
http://dl.ivtvdriver.org/datasheets/audio/WM8739.pdf


4. The baseband audio processing in the CX25841 could not be working or
have it's volume set too low. The volume controls available with
v4l2-ctl should let you set the volume and mute of this device. If
you're interested, the datasheet is here:

http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf

Sections 3.24 and 3.25 show the chip's audio processing capabilities.
I2S audio shoudl be coming in through Sample Rate Convertor (SRC) 1,
passing through a baseband processing path and exiting through SRC3 to
the CX23416. AC97 audio isn't used, and I'm fairly sure nor is
Ancillary mode audio.


So what do you feel like looking at first? I'd at least like you to
verify my overall block diagaram as best you can by visually inspecting
the traces on the board. (My diagram amounts to 1 big assumption right
now.)

Regards,
Andy


> Regards
> Ravi
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Mon, Jul 13, 2009 at 1:10 AM, Andy Walls<awalls@radix.net> wrote:
>> Hi Andy,
>>
>> The audio still does not work consistently with this version. Let me
>> know if there is any way I can check whether the new settings got
>> applied.
>
> Well, if you conpiled the modules with the CONFIG_ADV_DEBUG (?) option,
> then you can use v4l2-dbg to look at the registers of the chips.
> Something like this will show you the change is in effect:
>
> $ su - root
>
> # v4l2-dbg -d /dev/video0 -S
> host0: cx23416    revision 0x00000000
> i2c 0x1b: wm8775     revision 0x00000000
> i2c 0x44: cx25843    revision 0x00008433
>
> # v4l2-dbg -d /dev/video0 -c cx25840 --list-registers=min=0x110,max=0x113
> ioctl: VIDIOC_DBG_G_REGISTER
>
>          00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> 00000110: 0c 74 76 01
>          ^^^^^^^^^^^
>              |
> Indicator of the change, when set to line-in at 48 ksps.
>
>
>
> Here's my guess at the audio processing chain on your card:
>
>
>              +----------+                                       +---------------+
>              |     Sel0 |<--------------------------------------| GPIO14        |
>              |     Sel1 |<--------------------------------------| GPIO15        |
>              |          |                                       |               |
> (FM AF L)---->| 74HC4052 |                                       |               |
> (FM AF R)---->|          |         +----------------+------------|I2C Data & CLK |
>              | Dual 4:1 |         V                V            |               |
>              | Mux      |     +------+      +--------------+    |               |
> Line-in L --->|          |     |WM8739|      |   CX25841    |    |   CX23416     |
> Line-in R --->|          |---->|Analog|----->|I2S Data In   |    |               |
>              |          |---->|to I2S|------|I2S Clock     |    |               |
> White Conn?-->|          |     |Audio |      | I2S Data Out |--->|I2S Data In    |
>              |          |     +------+      | I2S Clock    |----|I2S Clock      |
>              +----------+                   |              |    |               |
> Tuner SIF ---------------------------------->|SIF In        |    +---------------+
>                                             |              |
>                                             +--------------+
>
>
> I realize your card doesn't have FM radio audio, but variants of it with
> the same PCB do have FM.
>
> The above picutre is just my guess.  Without having the card in hand,
> it's hard to actaully trace the wiring.  So let's look at where thing
> could be going wrong for Line-in audio:
>
>
> 1. I could be setting the 74HC4052 dual 4:1 multiplexer wrong.  The
> datasheet is here:
>
> http://www.datasheetcatalog.com/datasheets_pdf/7/4/H/C/74HC4052.shtml
>
> So if you could trace how line-in L & R run over to the chip, that would
> eliminate an unknown.
>
> 2. I could be using the wrong GPIO pins from the CX23416 for controlling
> the 74HC4052 mux.  Floating GPIO pins for driving the mux selection
> would explain why sometimes audio works and sometimes doesn't.  The best
> thing to do is to trace the selection inputs from the 74HC4052 back to
> the CX23416's BGA and figure out which balls in the grid are driving
> those lines.  An alternative would be to begin experimenting with pairs
> of GPIO pins in the ivtv-cards.c entry for your card, or use ivtv-ctl to
> manipulate GPIO pins interactively to see when audio works (or you
> change the state of the select pins on the 74HC4052 mux.
>
>
> 3. The WM8739 does actually have a volume control internally, that we
> are not explicitly setting - I'm using whatever the WM8739 module does
> by default.  v4l2-dbg could be used to set the WM8739 volume control
> registers manually to see if that makes audio work.
>
> The datasheet is here:
> http://dl.ivtvdriver.org/datasheets/audio/WM8739.pdf
>
>
> 4. The baseband audio processing in the CX25841 could not be working or
> have it's volume set too low.  The volume controls available with
> v4l2-ctl should let you set the volume and mute of this device.  If
> you're interested, the datasheet is here:
>
> http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
>
> Sections 3.24 and 3.25 show the chip's audio processing capabilities.
> I2S audio shoudl be coming in through Sample Rate Convertor (SRC) 1,
> passing through a baseband processing path and exiting through SRC3 to
> the CX23416.  AC97 audio isn't used, and I'm fairly sure nor is
> Ancillary mode audio.
>
>
> So what do you feel like looking at first?  I'd at least like you to
> verify my overall block diagaram as best you can by visually inspecting
> the traces on the board. (My diagram amounts to 1 big assumption right
> now.)
>
> Regards,
> Andy
>
>
>> Regards
>> Ravi
>>
>
>

Hi Andy,

I checked the MUX input connections and the signal path, and your
diagram is right. The MUX input pins are connected as follows -


+----------+
+---------------+
| Sel0 |<--------------------------------------|
GPIO14 |
| Sel1 |<--------------------------------------|
GPIO15 |
| | |
|
(FM AF L)--->| 74HC4052 | |
|
(FM AF R)--->|Y2 | +----------------+------------|I2C
Data & CLK |
| Dual 4:1 | V V |
|
| Mux | +------+ +--------------+ |
|
Line-in L -->| | |WM8739| | CX25841 | |
CX23416 |
Line-in R -->|Y1 |---->|Analog|----->|I2S Data In | |
|
| |---->|to I2S|------|I2S Clock | |
|
White Conn?->|Y0 | |Audio | | I2S Data Out |--->|I2S
Data In |
| | +------+ | I2S Clock |----|I2S
Clock |
+----------+ | | |
|
Tuner SIF---------------------------------->|SIF In |
+---------------+
| |


The MUX select final connections are not visible when they enter the
BGA area. So could not check the GPIO connections. But they seem to be
going to the general area where GPIO14/15 (balls B12/C11) are located,
but that is probably not enough to confirm.

Anyhow, I think it is not a MUX problem, because I was looking at this
block diagram and realized the tuner audio is a totally separate path.
However the tuner audio also behaves the same erratic way as Line-in
on the card (choppy/intermittent or totally silent). So could it be
something to do with CX23416 itself?


Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Tue, 2009-07-14 at 04:09 +0530, Ravi A wrote:
> On Mon, Jul 13, 2009 at 1:10 AM, Andy Walls<awalls@radix.net> wrote:
> >> Hi Andy,
> >>

> >
> > 1. I could be setting the 74HC4052 dual 4:1 multiplexer wrong. The
> > datasheet is here:
> >
> > http://www.datasheetcatalog.com/datasheets_pdf/7/4/H/C/74HC4052.shtml
> >
> > So if you could trace how line-in L & R run over to the chip, that would
> > eliminate an unknown.
> >
> > 2. I could be using the wrong GPIO pins from the CX23416 for controlling
> > the 74HC4052 mux. Floating GPIO pins for driving the mux selection
> > would explain why sometimes audio works and sometimes doesn't. The best
> > thing to do is to trace the selection inputs from the 74HC4052 back to
> > the CX23416's BGA and figure out which balls in the grid are driving
> > those lines. An alternative would be to begin experimenting with pairs
> > of GPIO pins in the ivtv-cards.c entry for your card, or use ivtv-ctl to
> > manipulate GPIO pins interactively to see when audio works (or you
> > change the state of the select pins on the 74HC4052 mux.
> >
> >
> > 3. The WM8739 does actually have a volume control internally, that we
> > are not explicitly setting - I'm using whatever the WM8739 module does
> > by default. v4l2-dbg could be used to set the WM8739 volume control
> > registers manually to see if that makes audio work.
> >
> > The datasheet is here:
> > http://dl.ivtvdriver.org/datasheets/audio/WM8739.pdf
> >
> >
> > 4. The baseband audio processing in the CX25841 could not be working or
> > have it's volume set too low. The volume controls available with
> > v4l2-ctl should let you set the volume and mute of this device. If
> > you're interested, the datasheet is here:
> >
> > http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
> >
> > Sections 3.24 and 3.25 show the chip's audio processing capabilities.
> > I2S audio shoudl be coming in through Sample Rate Convertor (SRC) 1,
> > passing through a baseband processing path and exiting through SRC3 to
> > the CX23416. AC97 audio isn't used, and I'm fairly sure nor is
> > Ancillary mode audio.
> >
> >
> > So what do you feel like looking at first? I'd at least like you to
> > verify my overall block diagaram as best you can by visually inspecting
> > the traces on the board. (My diagram amounts to 1 big assumption right
> > now.)
> >

>
> Hi Andy,
>
> I checked the MUX input connections and the signal path, and your
> diagram is right. The MUX input pins are connected as follows -
>
>
> +----------+ +---------------+
> | Sel0 |<--------------------------------------|GPIO14 |
> | Sel1 |<--------------------------------------|GPIO15 |
> | | | |
> (FM AF L)--->| 74HC4052 | | |
> (FM AF R)--->|Y2 | +----------------+------------|I2C Data & CLK |
> | Dual 4:1 | V V | |
> | Mux | +------+ +--------------+ | |
> Line-in L -->| | |WM8739| | CX25841 | |CX23416 |
> Line-in R -->|Y1 |---->|Analog|----->|I2S Data In | | |
> | |---->|to I2S|------|I2S Clock | | |
> White Conn?->|Y0 | |Audio | | I2S Data Out |--->|I2S Data In |
> | | +------+ | I2S Clock |----|I2S Clock |
> +----------+ | | | |
> Tuner SIF---------------------------------->|SIF In | +---------------+
> | |
>

Hi Ravi,

OK. I thought I saw in the picture Line In on Y1 and FM (from where the
TEA5767 should be) going into Y2. Thanks for confirming.


> The MUX select final connections are not visible when they enter the
> BGA area. So could not check the GPIO connections. But they seem to be
> going to the general area where GPIO14/15 (balls B12/C11) are located,
> but that is probably not enough to confirm.

Yes, I didn't expect tracing over to the BGA pins to be easy. Oh well.


> Anyhow, I think it is not a MUX problem, because I was looking at this
> block diagram and realized the tuner audio is a totally separate path.
> However the tuner audio also behaves the same erratic way as Line-in
> on the card (choppy/intermittent or totally silent).

The CX25841 can only decode BTSC (basic and dbx) broodcast audio.
Unless you have an NTSC RF source, I doubt the analog tuner assembly is
outputing valid SIF carrying BTSC. The Audio Standard Autodetection
microcontroller program inside the CX25841 will unmute the decoded and
dematrixed SIF audio only when it thinks it has valid audio (it can't
recall if it automatically mutes when good audio goes away). Without an
NTSC RF source, I'm afraid we can't entrirely eliminate the 4:1 Mux or
the WM8739.

I'm leaning towards the CX23481 configuration or the WM8739 causing line
in audio problems.

For the WM8739 volume control, mutes, master clock mode vs slave clock
mode are the only things I can think of right now. It's a pretty simple
chip.

For the CX25481 A/V lock of the Video and Aux PLLs might make things
better (in my test change for the cx25840 I have registers programed
with good values, but the AV lock bit set to disabled). And again
programming the the I2S clock on the I2S input to be in a different
mode. master or slave mode, might make a difference. I'll have to think
about it.


Can you use v4l2-dbg to dump all the CX25841 and WM8739 registers for
the case when line-in audio is working and for the case when it is not:

# su - root
# v4l2-dbg -d /dev/video0 -c cx25840 --list-registers
# v4l2-dbg -d /dev/video0 -c wm8739 --list-registers

maybe some differential analysis will help us see where a problem could
be.

> So could it be
> something to do with CX23416 itself?

I doubt it. The I2S input of the CX23416 is so simple and
non-configurable, it is probably something upstream from it.


Regards,
Andy

>
> Regards
> Ravi
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-07-16 at 11:32 +0530, Ravi A wrote:
> On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
>
> > Hi Ravi,
> >
> > OK. I thought I saw in the picture Line In on Y1 and FM (from where the
> > TEA5767 should be) going into Y2. Thanks for confirming.
> >
> >
> >> The MUX select final connections are not visible when they enter the
> >> BGA area. So could not check the GPIO connections. But they seem to be
> >> going to the general area where GPIO14/15 (balls B12/C11) are located,
> >> but that is probably not enough to confirm.
> >
> > Yes, I didn't expect tracing over to the BGA pins to be easy. Oh well.
> >
> >
> >> Anyhow, I think it is not a MUX problem, because I was looking at this
> >> block diagram and realized the tuner audio is a totally separate path.
> >> However the tuner audio also behaves the same erratic way as Line-in
> >> on the card (choppy/intermittent or totally silent).
> >
> > The CX25841 can only decode BTSC (basic and dbx) broodcast audio.
> > Unless you have an NTSC RF source, I doubt the analog tuner assembly is
> > outputing valid SIF carrying BTSC. The Audio Standard Autodetection
> > microcontroller program inside the CX25841 will unmute the decoded and
> > dematrixed SIF audio only when it thinks it has valid audio (it can't
> > recall if it automatically mutes when good audio goes away). Without an
> > NTSC RF source, I'm afraid we can't entrirely eliminate the 4:1 Mux or
> > the WM8739.
> >
> > I'm leaning towards the CX23481 configuration or the WM8739 causing line
> > in audio problems.
> >
> > For the WM8739 volume control, mutes, master clock mode vs slave clock
> > mode are the only things I can think of right now. It's a pretty simple
> > chip.
> >
> > For the CX25481 A/V lock of the Video and Aux PLLs might make things
> > better (in my test change for the cx25840 I have registers programed
> > with good values, but the AV lock bit set to disabled). And again
> > programming the the I2S clock on the I2S input to be in a different
> > mode. master or slave mode, might make a difference. I'll have to think
> > about it.
> >
> >
> > Can you use v4l2-dbg to dump all the CX25841 and WM8739 registers for
> > the case when line-in audio is working and for the case when it is not:
> >
> > # su - root
> > # v4l2-dbg -d /dev/video0 -c cx25840 --list-registers
> > # v4l2-dbg -d /dev/video0 -c wm8739 --list-registers
> >
> > maybe some differential analysis will help us see where a problem could
> > be.
> >
> >> So could it be
> >> something to do with CX23416 itself?
> >
> > I doubt it. The I2S input of the CX23416 is so simple and
> > non-configurable, it is probably something upstream from it.
> >
> >
> > Regards,
> > Andy
> >
> >>
> >> Regards
> >> Ravi
> >>
> >
> >
>
> Hi Andy,
>
> Sorry I could not get this done yet, as the entire setup was
> disassembled for the HT installation! I will do further debug today
> and tomorrow and report back the results.
>
> PS: where do I set the CONFIG_ADV_DEBUG option when compiling? I tried
> to google it but came up with just a couple of hits and no other
> information.

When compiling my ivtv repository snapshot (tip.tar.bz2) or cloned tree,
if you don't run 'make config', then this hsould be set in v4l/.config:

CONFIG_VIDEO_ADV_DEBUG=y

(If you do run 'make config' then make sure you set it.)

Then 'make' and 'make install'. Look to see that the modules that we
care about - wm8739, cx25840, ivtv - get compiled and installed.

Then 'make unload; make unload' and 'modprobe ivtv'.

Regards,
Andy

> Thanks
> Ravi
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:

>>
>> Hi Andy,
>>
>> I checked the MUX input connections and the signal path, and your
>> diagram is right. The MUX input pins are connected as follows -
>>
>>
>>              +----------+                                       +---------------+
>>              |     Sel0 |<--------------------------------------|GPIO14         |
>>              |     Sel1 |<--------------------------------------|GPIO15         |
>>              |          |                                       |               |
>> (FM AF L)--->| 74HC4052 |                                       |               |
>> (FM AF R)--->|Y2        |         +----------------+------------|I2C Data & CLK |
>>              | Dual 4:1 |         V                V            |               |
>>              | Mux      |     +------+      +--------------+    |               |
>> Line-in L -->|          |     |WM8739|      |   CX25841    |    |CX23416        |
>> Line-in R -->|Y1        |---->|Analog|----->|I2S Data In   |    |               |
>>              |          |---->|to I2S|------|I2S Clock     |    |               |
>> White Conn?->|Y0        |     |Audio |      | I2S Data Out |--->|I2S Data In    |
>>              |          |     +------+      | I2S Clock    |----|I2S Clock      |
>>              +----------+                   |              |    |               |
>> Tuner SIF---------------------------------->|SIF In        |    +---------------+
>>                                             |              |
>>
>
> Hi Ravi,
>
> OK.  I thought I saw in the picture Line In on Y1 and FM (from where the
> TEA5767 should be) going into Y2.  Thanks for confirming.
>
>
>> The MUX select final connections are not visible when they enter the
>> BGA area. So could not check the GPIO connections. But they seem to be
>> going to the general area where GPIO14/15 (balls B12/C11) are located,
>> but that is probably not enough to confirm.
>
> Yes, I didn't expect tracing over to the BGA pins to be easy.  Oh well.
>
>
>> Anyhow, I think it is not a MUX problem, because I was looking at this
>> block diagram and realized the tuner audio is a totally separate path.
>> However the tuner audio also behaves the same erratic way as Line-in
>> on the card (choppy/intermittent or totally silent).
>
> The CX25841 can only decode BTSC (basic and dbx) broodcast audio.
> Unless you have an NTSC RF source, I doubt the analog tuner assembly is
> outputing valid SIF carrying BTSC.  The Audio Standard Autodetection
> microcontroller program inside the CX25841 will unmute the decoded and
> dematrixed SIF audio only when it thinks it has valid audio (it can't
> recall if it automatically mutes when good audio goes away).  Without an
> NTSC RF source, I'm afraid we can't entrirely eliminate the 4:1 Mux or
> the WM8739.
>
> I'm leaning towards the CX23481 configuration or the WM8739 causing line
> in audio problems.
>
> For the WM8739 volume control, mutes, master clock mode vs slave clock
> mode are the only things I can think of right now.  It's a pretty simple
> chip.
>
> For the CX25481 A/V lock of the Video and Aux PLLs might make things
> better (in my test change for the cx25840 I have registers programed
> with good values, but the AV lock bit set to disabled).  And again
> programming the the I2S clock on the I2S input to be in a different
> mode. master or slave mode, might make a difference.  I'll have to think
> about it.
>
>
> Can you use v4l2-dbg to dump all the CX25841 and WM8739 registers for
> the case when line-in audio is working and for the case when it is not:
>
> # su - root
> # v4l2-dbg -d /dev/video0 -c cx25840 --list-registers
> # v4l2-dbg -d /dev/video0 -c wm8739 --list-registers
>
> maybe some differential analysis will help us see where a problem could
> be.
>
>> So could it be
>> something to do with CX23416 itself?
>
> I doubt it. The I2S input of the CX23416 is so simple and
> non-configurable, it is probably something upstream from it.
>
>
> Regards,
> Andy
>
>>
>> Regards
>> Ravi
>>
>
>

Hi Andy,

There seems to be some problem reading/writing registers -

-- transcript --
$ sudo v4l2-dbg -R type=i2cdrv,chip=cx25840,min=1,max=3
ioctl: VIDIOC_DBG_G_REGISTER

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
ioctl: VIDIOC_DBG_G_REGISTER failed for 0x1
ioctl: VIDIOC_DBG_G_REGISTER failed for 0x2
ioctl: VIDIOC_DBG_G_REGISTER failed for 0x3
00000000:
----

I confirmed that CONFIG_VIDEO_ADV_DEBUG is set in config file. There
also seems to be some difference in the command arguments v4l2-dbg
expects, from what you gave.

To check the MUX control/GPIO I measured the voltages on the sel pins
while switching the inputs using v4l2-ctl -i. Following is the result
-
sel0 sel1
---------------------
-i0 0V 0V
-i1 3.3V 0V
-i2 3.3V 0V
So it seems to be alright. However when I measured again when there is
no sound output, sel0 and sel1 were both at 0V. I then forced sel0 to
5V using a jumper wire, and the sound came back on!

It so happens the driver/utility is setting the input back to Y0
(default, white connector) whenever video format is changed -

$sudo v4l2-ctl -s pal
sets MUX input to Y0 from wherever it was. However -
$sudo v4l2-ctl --log-status
still shows the input to be Line-In!

$sudo v4l2-ctl -i1
$sudo v4l2-ctl -i2
sets the input back to Y1 and sound re-appears.

Is this how the behavior should be? I checked with MythTV too, and it
seems to be setting the video standard when starting, which is
switching off sound.

(by the way, the MUX supply is 5V but the sel inputs are at 3.3V level
- this seems to be marginal from the spec. Is there any way the GPIO
can be programmed to be 5V outputs?).


When MUX is set properly and sound is present, the volume was still a
bit low and it seemed very noisy - something like zero-crossing
distortion. I could improve it a bit by setting volume all the way
high.
sudo v4l2-ctl -c volume=65535
Setting bass and treble to '0' helped to reduce the distortion/noise
significantly although the volume still seemed low
sudo v4l2-ctl -c bass=0
sudo v4l2-ctl -c treble=0

If I can get v4l2-dbg to read/set registers maybe I can try more
experiments for the audio quality.

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, 2009-07-18 at 02:35 +0530, Ravi A wrote:
> On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
>

> >
>
> Hi Andy,
>
> There seems to be some problem reading/writing registers -
>
> -- transcript --
> $ sudo v4l2-dbg -R type=i2cdrv,chip=cx25840,min=1,max=3
> ioctl: VIDIOC_DBG_G_REGISTER
>
> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> ioctl: VIDIOC_DBG_G_REGISTER failed for 0x1
> ioctl: VIDIOC_DBG_G_REGISTER failed for 0x2
> ioctl: VIDIOC_DBG_G_REGISTER failed for 0x3
> 00000000:
> ----
>
> I confirmed that CONFIG_VIDEO_ADV_DEBUG is set in config file. There
> also seems to be some difference in the command arguments v4l2-dbg
> expects, from what you gave.

Hmmm. I know you need to be root (you did sudo, so that is Ok I think).
You may have to use the latest v4l2-dbg.

$ cd path_to_source_code/ivtv/v4l2-apps
$ make
(The make will halt for missing dependencies, but hopefully v4l2-dbg
gets built before that happens).
$ cd util
$ ./v4l2-dbg --help



> To check the MUX control/GPIO I measured the voltages on the sel pins
> while switching the inputs using v4l2-ctl -i. Following is the result
> -
> sel0 sel1
> ---------------------
> -i0 0V 0V
> -i1 3.3V 0V
> -i2 3.3V 0V
> So it seems to be alright. However when I measured again when there is
> no sound output, sel0 and sel1 were both at 0V.

Good experiment and good to know!


> I then forced sel0 to
> 5V using a jumper wire, and the sound came back on!

Good result, but don't do that again! When the CX23416 is driving a
GPIO as an out and trying to drive it low, fighting with an external
power supply trying to pull the line high may cause a damaging amount of
current to go through the CX23416's output driver.

The CX23416 datasheet that you can find with Goggle says that the GPIO's
are 5V tolerant and rated to handle up to 4 mA.


> It so happens the driver/utility is setting the input back to Y0
> (default, white connector) whenever video format is changed -
>
> $sudo v4l2-ctl -s pal
> sets MUX input to Y0 from wherever it was. However -
> $sudo v4l2-ctl --log-status
> still shows the input to be Line-In!
>
> $sudo v4l2-ctl -i1
> $sudo v4l2-ctl -i2
> sets the input back to Y1 and sound re-appears.
>
> Is this how the behavior should be?

Nope. Good observation, this is the bug. I checked the source code of
ivtv-gpio.c and the version history, and it's a bug that's been in the
ivtv driver since before it was in the mainline kernel.

It should be striaght-forward to fix the behavior, but I'll have to take
a look and make sure there's not some odd board that needs something
special. I'll have a patch ready soon.


> I checked with MythTV too, and it
> seems to be setting the video standard when starting, which is
> switching off sound.

That's probably normal.


> (by the way, the MUX supply is 5V but the sel inputs are at 3.3V level
> - this seems to be marginal from the spec. Is there any way the GPIO
> can be programmed to be 5V outputs?).

No. The CX23416 is a 3.3 V device according to the old datasheet out on
the web.

The Sn inputs of the 74HC4052 can go from 0 V to Vcc (the positive
suuply voltage). Looking at figure 14 of the 74HC4052 datasheet, it
would suggest that Vcc/2 is the needed turn on voltage. So even if Vcc
= 5V, 3.3 V is larger than 2.5 V by 1.2 V. I don't think the 3.3V will
be an issue, especially if Vcc to the 74HC4052 is 3.3V.

Regards,
Andy

> When MUX is set properly and sound is present, the volume was still a
> bit low and it seemed very noisy - something like zero-crossing
> distortion. I could improve it a bit by setting volume all the way
> high.
> sudo v4l2-ctl -c volume=65535
> Setting bass and treble to '0' helped to reduce the distortion/noise
> significantly although the volume still seemed low
> sudo v4l2-ctl -c bass=0
> sudo v4l2-ctl -c treble=0
>
> If I can get v4l2-dbg to read/set registers maybe I can try more
> experiments for the audio quality.
>
> Regards
> Ravi
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 2009-07-17 at 19:16 -0400, Andy Walls wrote:
> On Sat, 2009-07-18 at 02:35 +0530, Ravi A wrote:
> > On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:

> > It so happens the driver/utility is setting the input back to Y0
> > (default, white connector) whenever video format is changed -
> >
> > $sudo v4l2-ctl -s pal
> > sets MUX input to Y0 from wherever it was. However -
> > $sudo v4l2-ctl --log-status
> > still shows the input to be Line-In!
> >
> > $sudo v4l2-ctl -i1
> > $sudo v4l2-ctl -i2
> > sets the input back to Y1 and sound re-appears.
> >
> > Is this how the behavior should be?
>
> Nope. Good observation, this is the bug. I checked the source code of
> ivtv-gpio.c and the version history, and it's a bug that's been in the
> ivtv driver since before it was in the mainline kernel.
>
> It should be striaght-forward to fix the behavior, but I'll have to take
> a look and make sure there's not some odd board that needs something
> special. I'll have a patch ready soon.

Ravi,

I have pushed a patch to

http://linuxtv.org/hg/~awalls/ivtv


The bug was ancient. It looks like it arose from an old method of
setting the tuner back to TV when exiting from FM radio mode. It had
the side effect of changing the audio input of a GPIO audio mux back to
the tuner whenever the video standard was changed when you were not in
radio mode.

Apparently no one with a card with a GPIO audio mux ever changed the
standard when set to Composite or SVideo.



> > When MUX is set properly and sound is present, the volume was still a
> > bit low and it seemed very noisy - something like zero-crossing
> > distortion. I could improve it a bit by setting volume all the way
> > high.
> > sudo v4l2-ctl -c volume=65535
> > Setting bass and treble to '0' helped to reduce the distortion/noise
> > significantly although the volume still seemed low
> > sudo v4l2-ctl -c bass=0
> > sudo v4l2-ctl -c treble=0
> >
> > If I can get v4l2-dbg to read/set registers maybe I can try more
> > experiments for the audio quality.

Yes, it will give you the flexibility to experiment will all sorts of
audio settings.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, Jul 18, 2009 at 6:19 AM, Andy Walls<awalls@radix.net> wrote:
> On Fri, 2009-07-17 at 19:16 -0400, Andy Walls wrote:
>> On Sat, 2009-07-18 at 02:35 +0530, Ravi A wrote:
>> > On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
>
>> > It so happens the driver/utility is setting the input back to Y0
>> > (default, white connector) whenever video format is changed -
>> >
>> > $sudo v4l2-ctl -s pal
>> > sets MUX input to Y0 from wherever it was. However -
>> > $sudo v4l2-ctl --log-status
>> > still shows the input to be Line-In!
>> >
>> > $sudo v4l2-ctl -i1
>> > $sudo v4l2-ctl -i2
>> > sets the input back to Y1 and sound re-appears.
>> >
>> > Is this how the behavior should be?
>>
>> Nope.  Good observation, this is the bug.  I checked the source code of
>> ivtv-gpio.c and the version history, and it's a bug that's been in the
>> ivtv driver since before it was in the mainline kernel.
>>
>> It should be striaght-forward to fix the behavior, but I'll have to take
>> a look and make sure there's not some odd board that needs something
>> special.  I'll have a patch ready soon.
>
> Ravi,
>
> I have pushed a patch to
>
> http://linuxtv.org/hg/~awalls/ivtv
>
>
> The bug was ancient.  It looks like it arose from an old method of
> setting the tuner back to TV when exiting from FM radio mode.  It had
> the side effect of changing the audio input of a GPIO audio mux back to
> the tuner whenever the video standard was changed when you were not in
> radio mode.
>
> Apparently no one with a card with a GPIO audio mux ever changed the
> standard when set to Composite or SVideo.
>
>
>
>> > When MUX is set properly and sound is present, the volume was still a
>> > bit low and it seemed very noisy - something like zero-crossing
>> > distortion. I could improve it a bit by setting volume all the way
>> > high.
>> > sudo v4l2-ctl -c volume=65535
>> > Setting bass and treble to '0' helped to reduce the distortion/noise
>> > significantly although the volume still seemed low
>> > sudo v4l2-ctl -c bass=0
>> > sudo v4l2-ctl -c treble=0
>> >
>> > If I can get v4l2-dbg to read/set registers maybe I can try more
>> > experiments for the audio quality.
>
> Yes, it will give you the flexibility to experiment will all sorts of
> audio settings.
>
> Regards,
> Andy
>
>


Hi Andy,

With the latest patch, the MUX control becomes stable and the audio
stays put with video standard changes!

Now that the audio is stable, I notice some possible issue with the
PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
input). After 10 seconds of playing with mplayer the following is
output -
"Your system is too SLOW to play this! .. blah"
and after another 10 seconds a continuous stream of "Too many video
packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
audio are smooth.

I was able to finally read some registers after compiling the latest
v4l2-dbg. I will try tweaking audio registers using 82a264ea2784 next.

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, 2009-07-19 at 00:30 +0530, Ravi A wrote:
> On Sat, Jul 18, 2009 at 6:19 AM, Andy Walls<awalls@radix.net> wrote:
> > On Fri, 2009-07-17 at 19:16 -0400, Andy Walls wrote:
> >> On Sat, 2009-07-18 at 02:35 +0530, Ravi A wrote:
> >> > On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<awalls@radix.net> wrote:
> >
> >> > It so happens the driver/utility is setting the input back to Y0
> >> > (default, white connector) whenever video format is changed -
> >> >
> >> > $sudo v4l2-ctl -s pal
> >> > sets MUX input to Y0 from wherever it was. However -
> >> > $sudo v4l2-ctl --log-status
> >> > still shows the input to be Line-In!
> >> >
> >> > $sudo v4l2-ctl -i1
> >> > $sudo v4l2-ctl -i2
> >> > sets the input back to Y1 and sound re-appears.
> >> >
> >> > Is this how the behavior should be?
> >>
> >> Nope. Good observation, this is the bug. I checked the source code of
> >> ivtv-gpio.c and the version history, and it's a bug that's been in the
> >> ivtv driver since before it was in the mainline kernel.
> >>
> >> It should be striaght-forward to fix the behavior, but I'll have to take
> >> a look and make sure there's not some odd board that needs something
> >> special. I'll have a patch ready soon.
> >
> > Ravi,
> >
> > I have pushed a patch to
> >
> > http://linuxtv.org/hg/~awalls/ivtv
> >
> >
> > The bug was ancient. It looks like it arose from an old method of
> > setting the tuner back to TV when exiting from FM radio mode. It had
> > the side effect of changing the audio input of a GPIO audio mux back to
> > the tuner whenever the video standard was changed when you were not in
> > radio mode.
> >
> > Apparently no one with a card with a GPIO audio mux ever changed the
> > standard when set to Composite or SVideo.
> >
> >
> >
> >> > When MUX is set properly and sound is present, the volume was still a
> >> > bit low and it seemed very noisy - something like zero-crossing
> >> > distortion. I could improve it a bit by setting volume all the way
> >> > high.
> >> > sudo v4l2-ctl -c volume=65535
> >> > Setting bass and treble to '0' helped to reduce the distortion/noise
> >> > significantly although the volume still seemed low
> >> > sudo v4l2-ctl -c bass=0
> >> > sudo v4l2-ctl -c treble=0
> >> >
> >> > If I can get v4l2-dbg to read/set registers maybe I can try more
> >> > experiments for the audio quality.
> >
> > Yes, it will give you the flexibility to experiment will all sorts of
> > audio settings.
> >
> > Regards,
> > Andy
> >
> >
>
>
> Hi Andy,
>
> With the latest patch, the MUX control becomes stable and the audio
> stays put with video standard changes!
>
> Now that the audio is stable, I notice some possible issue with the
> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
> input). After 10 seconds of playing with mplayer the following is
> output -
> "Your system is too SLOW to play this! .. blah"
> and after another 10 seconds a continuous stream of "Too many video
> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
> audio are smooth.

Oops. The CX23416 firmware seems to be assuming a crystal value of
28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
crystal value of 28.636360 MHz for it's internal A/V decoder.

(I wish they had both assumed the correct value of 28.63636363... MHz.)

I'll have to get out my spreadsheet and recompute the values. I'll push
a patch tonight. I'll also try to test with my PVR-150 (but might not
get to testing it tonight).

Regards,
Andy

> I was able to finally read some registers after compiling the latest
> v4l2-dbg. I will try tweaking audio registers using 82a264ea2784 next.
>
> Regards
> Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, Jul 19, 2009 at 12:30 AM, Ravi A<asvravi@gmail.com> wrote:
>>
>>
>>> > When MUX is set properly and sound is present, the volume was still a
>>> > bit low and it seemed very noisy - something like zero-crossing
>>> > distortion. I could improve it a bit by setting volume all the way
>>> > high.
>>> > sudo v4l2-ctl -c volume=65535
>>> > Setting bass and treble to '0' helped to reduce the distortion/noise
>>> > significantly although the volume still seemed low
>>> > sudo v4l2-ctl -c bass=0
>>> > sudo v4l2-ctl -c treble=0
>>> >
>>> > If I can get v4l2-dbg to read/set registers maybe I can try more
>>> > experiments for the audio quality.
>>
>> Yes, it will give you the flexibility to experiment will all sorts of
>> audio settings.
>>
>> Regards,
>> Andy
>>
>>
>
>
> Hi Andy,
>
> With the latest patch, the MUX control becomes stable and the audio
> stays put with video standard changes!
>
> Now that the audio is stable, I notice some possible issue with the
> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
> input). After 10 seconds of playing with mplayer the following is
> output -
> "Your system is too SLOW to play this! .. blah"
> and after another 10 seconds a continuous stream of "Too many video
> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
> audio are smooth.
>
> I was able to finally read some registers after compiling the latest
> v4l2-dbg. I will try tweaking audio registers using 82a264ea2784 next.
>
> Regards
> Ravi
>

Hi Andy,

I experimented with the audio register settings on CX25840. I could
not seem to program the WM8739 though, there is no response with
$ sudo ./v4l2-dbg -c wm8739 -s 0x1a 0x80
And since wm8739 does not support register readback, I was not able to
verify the register settings.

Anyway, on the CX25840, increasing the volume and equalizers helped to
improve the SNR. I wish the this can be done on the WM8739 instead in
front of the ADC, so that the line level input signal (usually 320mV)
gets gained up to ADC input range of 1Vrms. Also note that there are
attenuating resistors in the signal path at input of WM8739, so the
gain may need to compensate for this too. Let me know if I am
mistaken.

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

> >
> > Hi Andy,
> >
> > With the latest patch, the MUX control becomes stable and the audio
> > stays put with video standard changes!
> >
> > Now that the audio is stable, I notice some possible issue with the
> > PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
> > d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
> > input). After 10 seconds of playing with mplayer the following is
> > output -
> > "Your system is too SLOW to play this! .. blah"
> > and after another 10 seconds a continuous stream of "Too many video
> > packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
> > Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
> > audio are smooth.
>
> Oops. The CX23416 firmware seems to be assuming a crystal value of
> 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
> crystal value of 28.636360 MHz for it's internal A/V decoder.
>
> (I wish they had both assumed the correct value of 28.63636363... MHz.)
>
> I'll have to get out my spreadsheet and recompute the values. I'll push
> a patch tonight. I'll also try to test with my PVR-150 (but might not
> get to testing it tonight).

Ravi,

I have pushed a patch to

http://linuxtv.org/hg/~awalls/ivtv

to adjust the PLL values used for CX2584x audio and video to assume a
crystal frequency of 28.636363 MHz is used.

Please test to see if the choppiness goes away.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:
>>> Hi Andy,
>>>
>>> With the latest patch, the MUX control becomes stable and the audio
>>> stays put with video standard changes!
>>>
>>> Now that the audio is stable, I notice some possible issue with the
>>> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
>>> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
>>> input). After 10 seconds of playing with mplayer the following is
>>> output -
>>> "Your system is too SLOW to play this! .. blah"
>>> and after another 10 seconds a continuous stream of "Too many video
>>> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
>>> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
>>> audio are smooth.
>>>
>> Oops. The CX23416 firmware seems to be assuming a crystal value of
>> 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
>> crystal value of 28.636360 MHz for it's internal A/V decoder.
>>
>> (I wish they had both assumed the correct value of 28.63636363... MHz.)
>>
>> I'll have to get out my spreadsheet and recompute the values. I'll push
>> a patch tonight. I'll also try to test with my PVR-150 (but might not
>> get to testing it tonight).
>>
>
> Ravi,
>
> I have pushed a patch to
>
> http://linuxtv.org/hg/~awalls/ivtv
>
> to adjust the PLL values used for CX2584x audio and video to assume a
> crystal frequency of 28.636363 MHz is used.
>
> Please test to see if the choppiness goes away.
>
> Regards,
> Andy
>
>

Hi Andy,

Out of luck, this still behaves the same - video and audio skips/jumps,
and also the error messages are still there.
Let me know if you need me to check anything else on this.

Regards
Ravi





_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, 2009-07-19 at 06:22 +0530, Ravi A wrote:
>
> Andy Walls wrote:
> >>> Hi Andy,
> >>>
> >>> With the latest patch, the MUX control becomes stable and the audio
> >>> stays put with video standard changes!
> >>>
> >>> Now that the audio is stable, I notice some possible issue with the
> >>> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
> >>> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
> >>> input). After 10 seconds of playing with mplayer the following is
> >>> output -
> >>> "Your system is too SLOW to play this! .. blah"
> >>> and after another 10 seconds a continuous stream of "Too many video
> >>> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
> >>> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
> >>> audio are smooth.
> >>>
> >> Oops. The CX23416 firmware seems to be assuming a crystal value of
> >> 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
> >> crystal value of 28.636360 MHz for it's internal A/V decoder.
> >>
> >> (I wish they had both assumed the correct value of 28.63636363... MHz.)
> >>
> >> I'll have to get out my spreadsheet and recompute the values. I'll push
> >> a patch tonight. I'll also try to test with my PVR-150 (but might not
> >> get to testing it tonight).
> >>
> >
> > Ravi,
> >
> > I have pushed a patch to
> >
> > http://linuxtv.org/hg/~awalls/ivtv
> >
> > to adjust the PLL values used for CX2584x audio and video to assume a
> > crystal frequency of 28.636363 MHz is used.
> >
> > Please test to see if the choppiness goes away.
> >
> > Regards,
> > Andy
> >
> >
>
> Hi Andy,
>
> Out of luck, this still behaves the same - video and audio skips/jumps,
> and also the error messages are still there.
> Let me know if you need me to check anything else on this.

Ok. I've pushed one more change to enable locking of the Aux PLL to the
video PLL. If this doesn't work, I'll leave out all the cx25840
changes.

Regards,
Andy


> Regards
> Ravi
>
>
>
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:
> On Sun, 2009-07-19 at 06:22 +0530, Ravi A wrote:
>
>> Andy Walls wrote:
>>
>>>>> Hi Andy,
>>>>>
>>>>> With the latest patch, the MUX control becomes stable and the audio
>>>>> stays put with video standard changes!
>>>>>
>>>>> Now that the audio is stable, I notice some possible issue with the
>>>>> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
>>>>> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
>>>>> input). After 10 seconds of playing with mplayer the following is
>>>>> output -
>>>>> "Your system is too SLOW to play this! .. blah"
>>>>> and after another 10 seconds a continuous stream of "Too many video
>>>>> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
>>>>> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
>>>>> audio are smooth.
>>>>>
>>>>>
>>>> Oops. The CX23416 firmware seems to be assuming a crystal value of
>>>> 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
>>>> crystal value of 28.636360 MHz for it's internal A/V decoder.
>>>>
>>>> (I wish they had both assumed the correct value of 28.63636363... MHz.)
>>>>
>>>> I'll have to get out my spreadsheet and recompute the values. I'll push
>>>> a patch tonight. I'll also try to test with my PVR-150 (but might not
>>>> get to testing it tonight).
>>>>
>>>>
>>> Ravi,
>>>
>>> I have pushed a patch to
>>>
>>> http://linuxtv.org/hg/~awalls/ivtv
>>>
>>> to adjust the PLL values used for CX2584x audio and video to assume a
>>> crystal frequency of 28.636363 MHz is used.
>>>
>>> Please test to see if the choppiness goes away.
>>>
>>> Regards,
>>> Andy
>>>
>>>
>>>
>> Hi Andy,
>>
>> Out of luck, this still behaves the same - video and audio skips/jumps,
>> and also the error messages are still there.
>> Let me know if you need me to check anything else on this.
>>
>
> Ok. I've pushed one more change to enable locking of the Aux PLL to the
> video PLL. If this doesn't work, I'll leave out all the cx25840
> changes.
>
> Regards,
> Andy
>
>
>
>
Hi Andy,

I just checked, it still has the same problem. Just to verify, I went
back to the 82a264ea2784 version again and that is smooth. Maybe you can
decide to leave out the cx25840 changes after testing on your PVR150
too, to double confirm.

Regards
Ravi





_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote:
>
> Andy Walls wrote:
> > On Sun, 2009-07-19 at 06:22 +0530, Ravi A wrote:
> >
> >> Andy Walls wrote:
> >>
> >>>>> Hi Andy,
> >>>>>
> >>>>> With the latest patch, the MUX control becomes stable and the audio
> >>>>> stays put with video standard changes!
> >>>>>
> >>>>> Now that the audio is stable, I notice some possible issue with the
> >>>>> PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and
> >>>>> d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite
> >>>>> input). After 10 seconds of playing with mplayer the following is
> >>>>> output -
> >>>>> "Your system is too SLOW to play this! .. blah"
> >>>>> and after another 10 seconds a continuous stream of "Too many video
> >>>>> packets in the buffer: (4096 in 8007268 bytes)... blah" appear.
> >>>>> Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and
> >>>>> audio are smooth.
> >>>>>
> >>>>>
> >>>> Oops. The CX23416 firmware seems to be assuming a crystal value of
> >>>> 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a
> >>>> crystal value of 28.636360 MHz for it's internal A/V decoder.
> >>>>
> >>>> (I wish they had both assumed the correct value of 28.63636363... MHz.)
> >>>>
> >>>> I'll have to get out my spreadsheet and recompute the values. I'll push
> >>>> a patch tonight. I'll also try to test with my PVR-150 (but might not
> >>>> get to testing it tonight).
> >>>>
> >>>>
> >>> Ravi,
> >>>
> >>> I have pushed a patch to
> >>>
> >>> http://linuxtv.org/hg/~awalls/ivtv
> >>>
> >>> to adjust the PLL values used for CX2584x audio and video to assume a
> >>> crystal frequency of 28.636363 MHz is used.
> >>>
> >>> Please test to see if the choppiness goes away.
> >>>
> >>> Regards,
> >>> Andy
> >>>
> >>>
> >>>
> >> Hi Andy,
> >>
> >> Out of luck, this still behaves the same - video and audio skips/jumps,
> >> and also the error messages are still there.
> >> Let me know if you need me to check anything else on this.
> >>
> >
> > Ok. I've pushed one more change to enable locking of the Aux PLL to the
> > video PLL. If this doesn't work, I'll leave out all the cx25840
> > changes.
> >
> > Regards,
> > Andy
> >
> >
> >
> >
> Hi Andy,
>
> I just checked, it still has the same problem. Just to verify, I went
> back to the 82a264ea2784 version again and that is smooth. Maybe you can
> decide to leave out the cx25840 changes after testing on your PVR150
> too, to double confirm.

I just think I figured out the problem. The I2S master clock has to be
running at 384 clocks per sample. My computations are ensuring it's 384
clock per sample for Broadcast decoder (TV tuner audio) output, and 256
clocks per sample on Line in I2S input. The reason I did this was that
on the input side of the CX2584x the decoder uses 384 and the I2S input
uses 256. This is likely the problem.

I'll figure out new numbers and try again.... maybe tomorrow. :)

Regards,
Andy


> Regards
> Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, 2009-07-18 at 21:31 -0400, Andy Walls wrote:
> On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote:

> > >
> > Hi Andy,
> >
> > I just checked, it still has the same problem. Just to verify, I went
> > back to the 82a264ea2784 version again and that is smooth. Maybe you can
> > decide to leave out the cx25840 changes after testing on your PVR150
> > too, to double confirm.
>
> I just think I figured out the problem. The I2S master clock has to be
> running at 384 clocks per sample. My computations are ensuring it's 384
> clock per sample for Broadcast decoder (TV tuner audio) output, and 256
> clocks per sample on Line in I2S input. The reason I did this was that
> on the input side of the CX2584x the decoder uses 384 and the I2S input
> uses 256. This is likely the problem.
>
> I'll figure out new numbers and try again.... maybe tomorrow. :)

OK, I lied. The latest change for the cx25840 module is at

http://linuxtv.org/hg/~awalls/ivtv

I haven't tested it, but I will have to to make sure Tuner audio still
works. Please test line in audio if you can.

(now I'm going to bed...really...)

regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:
> On Sat, 2009-07-18 at 21:31 -0400, Andy Walls wrote:
>
>> On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote:
>>
>
>
>>>>
>>>>
>>> Hi Andy,
>>>
>>> I just checked, it still has the same problem. Just to verify, I went
>>> back to the 82a264ea2784 version again and that is smooth. Maybe you can
>>> decide to leave out the cx25840 changes after testing on your PVR150
>>> too, to double confirm.
>>>
>> I just think I figured out the problem. The I2S master clock has to be
>> running at 384 clocks per sample. My computations are ensuring it's 384
>> clock per sample for Broadcast decoder (TV tuner audio) output, and 256
>> clocks per sample on Line in I2S input. The reason I did this was that
>> on the input side of the CX2584x the decoder uses 384 and the I2S input
>> uses 256. This is likely the problem.
>>
>> I'll figure out new numbers and try again.... maybe tomorrow. :)
>>
>
> OK, I lied. The latest change for the cx25840 module is at
>
> http://linuxtv.org/hg/~awalls/ivtv
>
> I haven't tested it, but I will have to to make sure Tuner audio still
> works. Please test line in audio if you can.
>
> (now I'm going to bed...really...)
>
> regards,
> Andy
>
>

Hi Andy,

You were right on time for me to test it as soon as I woke up :)
This version seems much better. The skip/jump has gone away! However I
notice some video/audio dropouts after a few seconds of playing, and the
"too many video packets in buffer" messages too. The good news is, the
82a264ea2784 version is also showing these dropouts - I am certain it
was smooth before, so a bit puzzled as to why I am seeing these dropouts
now! But anyway the latest PLL VCO change version seems same as earlier
versions now. I have not compared with 32KHz audio sampling yet though.

Do let me know if there is anything I can check to eliminate or isolate
the driver settings as the cause for the audio/video dropouts. The
machine itself and components are fast and I am able to play 1080p video
from local disks smoothly.

It might help if there can be another independent testing on this version.

Regards
Ravi




_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel