On Sat, 2010-02-13 at 14:32 -0500, Devin Heitmueller wrote: > On Sat, Feb 13, 2010 at 1:35 PM, Kyle Lil <[email protected]> wrote: > > The hard drive is being accessed pretty frequently (~1/second) when watching > > tv with mythtv, much more often than the errors are appearing. So, the hard > > drive cannot reliably produce the errors. Interestingly, I think the errors > > seem to occur slightly more often when watching tv with myth than when just > > monitoring the signal with azap. Would azap catch all errors or does it just > > sparsely sample the signal? > > The optical drive is not spinning up and the graphics card is fanless. The > > only other significant EMI sources inside the computer that I can think of > > are the case fan, cpu fan, and maybe the power supply. I can play around > > with different ground configurations to see if that helps. > > Kyle, > > Just to be clear, the BER/UNC counters count the number of errors > *only* between the tuner and demodulator. These are errors where the > Reed-Solomon error correction built into the signal could not > compensate (essentially errors in the analog signal transmission). > I'm pointing this out to make clear that those counters do not track > any *other* possible class of problem,
Devin, Right. My statement about EMI was that signals inside the computer are affecting the IF signal on the card. (Sometime back on a list that I monitor, I recall someone with a disk controller right next to their TV capture card causing problems. Moving the TV card away from the disk controller card fixed the issue.) Since SNR wasn't really changing for Kyle, my guess was the errors come from strong "narrowband" and/or "burst" noise superimposed onto the IF from within his computer. Since the operation of the computer internals could easily behave differently between Windows and Linux, this seemed plausible to explain different results between Linux to Windows. The SNR reported for QAM is just a conversion from an averaged quantity being reported by the chip. I suppose the averaging interval could be hiding actual error bursts coming down the cable, so we never see SNR dip. However that would not explain why he didn't notice any video defects under Windows (assuming the Windows rendering app and linux rendering app handle errors in the same way). > such as packets being lost in > the cx18 driver, the application's failure to read the packets from > the driver fast enough (resulting in the packets being dropped by the > driver), or problems writing the MPEG frames to the hard disk, etc. My suggestion was more about disk activity causing EMI internal to the PC case. I had in mind perhaps a disk controller card next to the HVR-1600. Regards, Andy > Devin _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
