On Wed, 2009-09-02 at 23:25 -0500, Chris Kennedy wrote:
> > > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <[email protected]> wrote:
> > >
> > >> 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.
>
> I had this happen again tonight, upon a capture start it seems
> that the audio was bad. So I got snapshots of the registers
> when I know it was bad, and after I fixed it, all manually. So
> these register captures may be more helpful then the last ones
> since I had turned off my fix script.
>
> Thanks,
> Chris
I looked at the differences and what it boils down to appears to be a
misdetection of SAP (lang2) being available. Here's the only
interesting part of the difference:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-00000800: fe 3f e0 13 10 0f 8d 00 f6 04 11 00 00 00 0c 20
+00000800: fe 3f e0 13 00 0f 8d 00 f6 04 11 00 00 00 0c 20
^^
Detected SAP (lang2) vs just mono
-00000810: 00 02 ff 82 05 09 14 20 c0 31 00 00 d1 05 80 47
+00000810: 00 02 ff 88 05 09 14 20 c0 31 00 00 d1 05 80 47
^^
Audio interrupt status:
RDS asserted | Audio mode changed asserted
vs.
RDS asserted | Format detection loop complete asserted
-00000820: 00 28 00 80 44 e5 44 e5 a8 54 7e 00 f2 07 01 24
+00000820: 00 28 00 80 44 e5 84 e5 a8 54 7e 00 f2 07 01 24
^^
Interesting, but no public description available.
There are also some SRC status differences:
-000008f0: fc 0a 00 88 88 88 55 55 7c 86 01 08 7c 86 01 08
+000008f0: fc 0a 52 bb 88 88 55 55 7c 86 01 08 7c 86 01 08
^^ ^^
SRC4 Left overflow, SRC3 Left & Right underflow
and other differences
I find it interesting that when SAP was detected, there was no Format
Detection loop complete assertion. I left my reference material on BTSC
at work, so I can't guess about how a misdetection of SAP would come
about.
The end action is still the same I think:
poll or catch interrupts for when the audio microcontroller tries to
change things on it's own, and depending on some criteria, reset the
audio microcontroller.
I suspect I'll have to set up a poll for the general case anyway. I'll
base the reset criteria on detecting SAP, the state of bits 1:3 of
register 0x813, and some internal state.
Maybe I'll have something worth testing this weekend.
Regards,
Andy
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
