On Fri, 2010-06-11 at 22:03 -0400, Dale Pontius wrote:
> On 06/10/10 23:14, Andy Walls wrote:
> 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.
Well, some things to try:
1. remove all instances of the cx18-alsa.ko module from
under /lib/modules. It shouldn't matter, but most users never need it,
If hald or pulseaudio has it open, you may be unable to switch away from
48 ksps and then back.
2. When you have no audio, try using v4l2-ctl to switch from the tuner
audio to line in audio and back. You could also stop then capture,
switch to 44.1 ksps or 32 ksps and then restart the capture.
> 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.
Whenever I see
Verification method: inspection
in a design review, my internal alarm bells go off.
Unfortunately, without proper instrumentation and engineering
documentation, we're left with Easter-egg hunting for solutions. We can
narrow down the problem to "somewhere around here", but then we're stuck
trying a myriad of end user actions and hoping something works against
an intermittent problem. Lack of determinism in the problem and
process makes finding solutions a lengthy process.
> 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.
I don't know. With PC hardware, there's a really big waterfront in terms
of hardware permutations and parts quality. So the question becomes
"what hardware"? For example, you can search the list for how well a
CX23415/6 interacts with a VIA PCI chipset.
The difficulties caused by the number of possible hardware
permutationsat is managed in the Windows world by WHQL and OEMs putting
together media center PCs in only standard, known good configurations.
Regards,
Andy
> Thanks for all of your thought and consideration,
> Dale
>
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
