Thanks for your insight, Hans. I will endeavor to update to the latest kernel and ivtv drivers, and I'll let you know what I find.
Now I just need some free time... ;-) Regards, Mike Ellis On May 12, 2008, at 7:45 AM, Hans Verkuil <[EMAIL PROTECTED]> wrote: > On Saturday 10 May 2008 14:42:52 Michael Ellis wrote: >>>> 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. > > Hi Mike, > > The tinny audio problem plagued a lot of people in the past, but I > haven't heard about this for quite some time now. Please make sure you > are using the latest version (preferably the 'bleeding edge' code from > http://www.ivtvdriver.org/index.php/Download#Bleeding_Edge_driver). > > It seems that this problem only hits NTSC cards and it seems to be > related to some interaction between the audio chip and the cx23416. > After I made some changes in the way this is handled the problem > disappeared, although I never quite understood what was going on > internally. And I think that in one or two cases it was actually a bad > card, so I wonder if you could get hold of another PVR500 to test > with. > > Regards, > > Hans > >> 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 > > _______________________________________________ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
