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
