On Fri, 2009-09-04 at 10:15 -0400, Andy Walls wrote: > 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.
Chris, I've got a change to poll the audio interrupt status evry x milliseconds and log if anything has changed and to log if the driver did not force the change. http://linuxtv.org/hg/~awalls/cx25840 To observe audio microcontroller status changes do this: # modprobe cx25840 debug=3 aud_status_poll_ms=100 # modprobe ivtv # ivtv-tune -d /dev/video0 -c3 /dev/video0: 61.250 MHz # dmesg My DTV to NTSC-M STB shows this at the end of the dmesg, after the above steps [14333.850659] cx25840 1-0044: PLL = 108.000011 MHz [14333.850661] cx25840 1-0044: PLL/8 = 13.500001 MHz [14333.850663] cx25840 1-0044: ADC Sampling freq = 14.317384 MHz [14333.850666] cx25840 1-0044: Chroma sub-carrier freq = 3.579545 MHz [14333.850669] cx25840 1-0044: hblank 122, hactive 720, vblank 26, vactive 487, vblank656 26, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c1f [14333.885857] cx25840 1-0044: decoder set video input 7, audio input 8 [14355.908454] cx25840 1-0044: Audio status: rds fdl afc [14355.908468] cx25840 1-0044: Audio format change occured [14355.908473] cx25840 1-0044: Audio format detection loop complete [14355.917311] cx25840 1-0044: Detected audio mode: mono [14355.917320] cx25840 1-0044: Detected audio standard: BTSC [14355.917324] cx25840 1-0044: Audio muted: no [14355.917328] cx25840 1-0044: Audio microcontroller: detecting [14355.917333] cx25840 1-0044: Configured audio standard: automatic detection [14355.917338] cx25840 1-0044: Configured audio system: BTSC [14355.917342] cx25840 1-0044: Specified audio input: Tuner (In8) [14355.917347] cx25840 1-0044: Preferred audio mode: stereo [14372.742145] cx25840 1-0044: Audio status: rds afc [14372.742158] cx25840 1-0044: Audio format change occured [14372.742164] cx25840 1-0044: ... after initial format detection loop completed! [14372.750646] cx25840 1-0044: Detected audio mode: mono [14372.750656] cx25840 1-0044: Detected audio standard: BTSC [14372.750660] cx25840 1-0044: Audio muted: no [14372.750664] cx25840 1-0044: Audio microcontroller: running [14372.750669] cx25840 1-0044: Configured audio standard: automatic detection [14372.750674] cx25840 1-0044: Configured audio system: BTSC [14372.750678] cx25840 1-0044: Specified audio input: Tuner (In8) [14372.750683] cx25840 1-0044: Preferred audio mode: stereo The RDS status always appears to be set, so ignore it. The first Audio Format Change (AFC) happens at the same time as the Format Detection Loop (FDL) complete state. Then another AFC happens and some Audio Mode Changes (amc) that I don't show. These AMC & AFC events continue to occur. I haven't tried to correlate them with commercials, etc. yet. This isn't a complete solution yet. I'm not quite sure under what condition to declare the audio standard misdetected (tinny audio) and force the microcontroller to try again. Could you test things with this change in place to see if there are any other indicators of "tinny audio" other than "mono lang2"? Regards, Andy > Regards, > Andy > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
