On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<[email protected]> 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
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
