awalls at radix
Jul 13, 2009, 5:37 PM
On Tue, 2009-07-14 at 04:09 +0530, Ravi A wrote:
Re: Fwd: [UNKNOWN IVTV CARD] (cx23416) AverMedia M113-C
[In reply to]
> On Mon, Jul 13, 2009 at 1:10 AM, Andy Walls<awalls [at] radix> 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 | +---------------+
> | |
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
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
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
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
> 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.
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver