>> Course of action #2: >> Alternatively, if Mike Ellis can confirm that he never has tinny >> audio >> with a particular ivtv version (0.6.7), a diff between that and >> version >> 1.0.3 would show all the potential areas of a root cause in the >> driver. >> But the changes between these two versions are probably extensive. >>
Hi Andy. I'm afraid you may have misunderstood my comments. I did say that I settled on 0.6.7, but I did not mean to imply that 0.6.7 fixed the tinny audio problem. In fact, I've been fighting the tinny audio problem on my PVR500 since I setup my system back in 2006. 0.6.7 ended up being the best compromise for me based on the kernel I want to use, but I've observed tinny audio all the way from 0.6.x through the 1.0.x drivers (I used 1.0.x when I was experimenting with newer kernels -- I later reverted). The folks I've spoken to who've worked around this problem use a channel change script to toggle the audio settings each time the channel changes, but I have been procrastinating in setting that up. Put simply: the tinny audio problem appears regardless of whether you are using earlier ivtv drivers for some of the most recent ones. Consequently, I doubt the issue is due to a code change in the driver, and it is more likely due to the way the chips are being configured. Hope this helps. Mike Ellis > ------------------------------ > > Message: 2 > Date: Fri, 09 May 2008 21:26:49 -0400 > From: Andy Walls <[EMAIL PROTECTED]> > Subject: Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3 > To: User discussion about IVTV <ivtv-users@ivtvdriver.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Fri, 2008-05-09 at 21:28 -0300, Kevin Blair wrote: >> upgrade to myth .21 didnt do anything, i tried a pvr250 i have and it >> doesnt seem to do it, i have a second pvr150 card in the second >> system >> which i swaped to rule out hardware (and chipset it has a older >> revision) but no difference. also tried older and "newer"(was same as >> current) firmware, wouldnt take old, no change otherwise. >> i tried the newi2c option, no change. >> im not using the pvr250 cause the svid input quality is bad. >> >> less of getting a new card im out of ideas. > > Well it boils down to this, there are only three chips that handle > audio > on the card: > > 1. the baseband audio digitizer/multiplexer/serializer (the wm8775 is > the one on my PVR-150MCE) > > 2. the broadcast decoder, digitizer, with digital baseband audio > processing (the cx28543 on my PVR-150MCE) > > 3. the MPEG encoder (the cx23416) > > I don't have any real insight into the cx23416 encoder, so I'm going > to > wave my hands and assume its working properly for now. > > That leaves the cx25843 and the wm8775 as source of the tinny audio. > For them to do that, under certain conditions one of these must be > true: > > a) the driver is not setting these chip up properly, or > b) the chip isn't behaving properly. > > The wm8775 is a pretty simple device, so the odds of it behaving > improperly are low. If this device is what is introducing the tiny > audio, the driver must not be setting it up properly. > > The cx28543 is a bit more complex so it could either the driver not > setting it up properly or it misbehaving. > > Also, note you have the problem with baseband audio in, and not with > tuner audio (which bypasses the wm8775 in the common case of SIF audio > being fed into the cx25843). > > So here are three courses of action you could undertake to try and > find > the source of the problem. > > Course of action #1: > To verify if the driver is setting up all the registers properly is > conceptually easy: > > 1. With good audio, use v4l-dbg to dump all the registers of the > cx25843 > and wm8775. > > 2. With bad audio, but otherwise the same exact configuration, use > v4l-dbg to dump all the registers of the cx25843 and wm8775. > > 3. Do a "diff" (or use vimdiff) and see what registers differ. If > none > differ, a device must be misbehaving. > > 4. If registers do differ, check the datasheets at dl.ivtvdriver.org > to > see if any are related to audio processing. If so, you may have found > the register the driver or on chip autoconfig screwed up. If not, a > device is misbehaving. > > 5. If a device is misbehaving, v4l-dbg can be used to tweak individual > register settings to of the cx28543 or wm8775 to hunt for causal > relationships by trial and error (blech!) > > Here's the problem with that: > I believe the cx25840 driver support register dumps via v4l-dbg, but > I'm > pretty sure the wm8775 driver does not. It should be simple to add, > so > I can work up a patch, if you want to go through some of the steps > above > to hunt this down. > > > Course of action #2: > Alternatively, if Mike Ellis can confirm that he never has tinny audio > with a particular ivtv version (0.6.7), a diff between that and > version > 1.0.3 would show all the potential areas of a root cause in the > driver. > But the changes between these two versions are probably extensive. > > > Course of action #3: > If neither of those turn up any obvious answers, then one can start > doing differential analysis of cx23416 register settings, and hope > something that one doesn't need that datasheet to understand will jump > out. > > > Those are my ideas. All three of them are a non-trivial amount of > work. > > Anyone have any others? > > > -Andy ========================= Michael F. Ellis President Ellis Softworks Inc. ---------- Phone: (941) 713-0361 Email: [EMAIL PROTECTED] Web: http://www.ellissoftworks.com _______________________________________________ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
