On Sat, 2009-08-29 at 20:39 -0500, Chris Kennedy wrote:

> I'm wondering too if it's signal dependent, could be something in the
> signal triggers this behavior, perhaps my signal changed recently and
> the new kernel was coincedental.  Also I have seen it twice in a month
> on 4 interfaces, I only really look at one interface daily of those,
> so it in theory could have happened before and I just never was lucky
> enough to catch it.  I did go for 4+ months though before without 
> seeing it, so seems like it did change with the kernel change, but also
> the machine changed too (although it's an exact duplicate) so again it 
> could be some signal thing or even hardware/cards that are slightly 
> different.

Well the "tinny audio" problem - and this looks like it - is almost
certainly signal dependent.

We don't really muck with the audio registers once tuned to a channel.
The audio microcontroller is the only control program modifying the
non-publicly documented audio related registers.  In my mind, a change
in the broadcast signal (between programs, or program/commerical
boundary?) has to be causing it to readjust.  Sometimes that
readjustment is not right apparently.

The questions to answer really are:

1. How do we automatically detect the condition before the audio is
badly affected?

2. What to do about it, when we detect it?


The answer to #2 is pretty straightforward in my mind: reset the audio
microcontroller.  That's what your '--set-audio-input=0' essentially
does.  Perhaps there may need to be an extra step of waiting for the
"video present" status to show up, but the corrective action is still
the same.

The answer to #1 is probably hard.  It may be easier to assume that
whenever the audio microcontroller detects an audio format or mode
change on its own (not initiated by the linux driver), we should check
and take some corrective or preventative action.


All that might not be an option, if the IRQ_N of the CX25843 isn't wired
up. 


Let me know if you find a pattern in the errant condition.

Regards,
Andy



_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to