On Tue, 2009-07-14 at 04:09 +0530, Ravi A wrote: > On Mon, Jul 13, 2009 at 1:10 AM, Andy Walls<[email protected]> 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 [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
