On 06/10/10 23:14, Andy Walls wrote: > On Wed, 2010-06-09 at 19:48 -0400, Dale Pontius wrote: >> On 06/04/10 21:42, Andy Walls wrote: >> <snip> >>>> cx18-0 843: Video signal: present >>>> cx18-0 843: Detected format: NTSC-M >>>> cx18-0 843: Specified standard: NTSC-M >>>> cx18-0 843: Specified video input: Composite 7 >>>> cx18-0 843: Specified audioclock freq: 48000 Hz >>>> cx18-0 843: Detected audio mode: mono >>>> cx18-0 843: Detected audio standard: no detected audio standard >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> | >>> And this is what makes me pull my hair out. ----+ >>> >>> Same card, same chipset, same firmware image, in the same PC and mobo, >>> same TV channel with the same RF signal, same analog tuner assembly, and >>> one '843 core detects the audio standard and the other '843 core >>> doesn't. :P >>> >>> If you have controlled the signal levels properly and used good cable >>> and grounding, the difference has to be in the analog tuner can. Either >>> it has gone bad, or it is picking up a lot of noise from somewhere. >>> >>> Come to think of it, a bad analog tuner assembly could explain the red >>> screen. >>> >>> Anyway, if *everthing* is the same, and one card works and one card >>> doesn't, there's nothing to be done in software - except implement >>> workaround that may not work. I *speculate* that you have a dying card. >>> >> To continue contributing to sales of Rogaine... >> >> This evening I finally got a few minutes to rub together, so I've done >> an experiment. I shut down mythbackend, then started rmmoding as much >> of the cx18 stuff as I could positively identify using modules.dep. The >> idea was to "shut off" the cards with nothing else significant going on >> with the system, like a power-down or reboot. > > Hmmm. Once some of those components are powered and enabled by > software, they are never disabled. The digital tuner and demodulator > chips come to mind. I think the analog ones are always consuming power > (with slightly more power used when left tuned to higher channel > frequencies due to running the oscillators faster). > Thanks for all of the thought, but last night/today/just-now I think I shot any theories full of holes.
The weather has been warming today, but last night I shut the computer down. Regular shutdown, not full power-off, so 5VSB was still on, which is at least significant to the red-screen. This morning, in the cold, I powered on - no audio. A little later I rebooted, still no audio. So much for it being largely about temperature. It has warmed quite a bit today, and this evening I had a few minutes, so I removed all of the modules, then modprobed cx18 and cx18-alsa. I have sound, again. It's just flakey. Maybe when I get a break and take this system down, a bit of dust-off and reseating cards will work wonders. I had been focusing on initialization, partly because when we're analyzing, we analyze the major modes of operation practically to death, especially the performance-critical ones. There are things you can do to simulate end-of-life device shifts, etc, and we do those. For the power circuitry you analyze power-up to death, too. But initialization is one of those typically non-critical things that you logically verify. Schedules are schedules, and you want to do a thorough job, but usually something has to give, and it's the less-used stuff that hasn't failed in the past. (The opposite is "analysis paralysis", where you keep analyzing past the accuracy of your simulator to really tell you anything. The ultimate judge is hardware. But then again, I've never done consumer electronics, and maybe their mindset is different. Thanks for all of your thought and consideration, Dale _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
