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 _______________________________________________ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
