On Sat, Aug 29, 2009 at 05:14:49PM -0400, Andy Walls wrote: > On Sat, 2009-08-29 at 01:04 -0500, Chris Kennedy wrote: > > On Fri, Aug 28, 2009 at 09:00:58PM -0400, Andy Walls wrote: > > > On Fri, 2009-08-28 at 16:49 -0500, Chris Kennedy wrote: > > > > On Fri, Aug 28, 2009 at 04:31:13PM -0500, Chris Kennedy wrote: > > > > > On Fri, Aug 28, 2009 at 03:40:07PM -0400, Andy Walls wrote: > > > > > > On Fri, 2009-08-28 at 12:01 -0500, Chris Kennedy wrote: > > > > > > > > > > > > > > > > > > If you can reproduce again, maybe use v4l2-dbg to dump the > > > > > > registers of > > > > > > the cx25840 and compare the good and the bad cases. I suspect > > > > > > registers > > > > > > in the 0x800-0x8ff range will jump out as being very different. It > > > > > > won't explain the failure mode however... > > > > > > > > > > I've got a script that I am running which checks for the > > > > > oddity in audio subchannels and resets the audio input to > > > > > 0 when not just mono. I put into that a v4l2-dbg command to > > > > > dump the registers, so I should be able to catch the state > > > > > of the registers to my log file when this happens. > > > > > > > > Right away after running my catch script, it happens to > > > > have caught this happening almost always on driver > > > > load. Actually not always, out of the 4 inputs usually > > > > 3 or so will have this odd mono lang2 state. I'm guessing > > > > this may be the natural state before audio detection, > > > > so when this happens the chip just wasn't able to detect > > > > audio standards correctly or something like that (and seems > > > > calling the audio input set command makes it try again and > > > > usually works that time). > > > > > > Hmmm. Another guess, maybe with the newer kernel version, perhaps > > > cx25840 firmware load worker thread is completing faster than initial > > > tuner setup in ivtv-driver.c (I'm assuming it wasn't with the old > > > kernel), so the SIF is not stable when the CX25843 firmware is loaded > > > and set running. > > > > > > Just another guess really. > > > > > > > > > > So here's the main diffs between the registers, from 2 different > > > > inputs to help. I'll see if it ever does this outside a restart, > > > > and will see if I can find a time when it does this and truly > > > > messes up audio (in these cases it's probably not fully > > > > initialized or detecting audio yet, I'm guessing, but interesting > > > > that this is exactly the same subchannels it shows when the > > > > audio is messed up). > > > > > > I suspect you're right about the default state. > > > > > > I'll take a look at these diffs tomorrow. > > > > > > Regards, > > > Andy > > > > > > > These are diffs of bad vs. good, so - is from bad state > > > > and + is when back into good state. > > > > > > > > -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11 > > > > +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11 > ^^ > GPIO inputs are floating around. > > > > > -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 00 00 > > > > +00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 81 35 00 > ^^ ^^ > Odd vs. Even field (don't care) > Video present, VGA locked, Vertical lock, Horizontal lock - big > difference > > > > > -00000410: bf 01 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00 > > > > +00000410: bf 07 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00 > ^^ > Macrovision detect changed, Vid Present changed > > > > > -00000480: 26 00 00 00 00 00 00 42 1b 97 05 f8 dc 40 10 00 > > > > +00000480: 5b 00 00 00 00 00 60 42 17 d3 07 f8 dc 40 10 00 > ^^ ^^ ^^^^^^^^ > Field count and test register (don't care) > Variable Gain amplifier gain and AGC is different - no surprise given > the above > > > > > > -00000800: fe 3f 02 13 fe ff 8d 00 f6 04 01 00 00 00 1c 60 > > > > +00000800: fe 3f f8 13 fe ff 8d 00 f6 04 11 00 00 00 1c e0 > ^^ ^^ ^^ > DL Port - con't care when not in memory map mode > Video present (in the line with a +), but in both cases the > microcontroller claims to know the video format! > > > > > -00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 53 47 > > > > +00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47 > ^^ > > > > -00000820: 16 4a ce 1b 85 e0 05 8a a0 01 00 00 e9 01 ed 03 > > > > +00000820: 53 44 ce 1b 05 e0 05 8a a0 01 00 00 e9 01 ed 03 > ^^^^^ ^^ > > > > > -00000840: 00 00 00 40 00 00 ed 03 10 80 84 1e 00 00 00 40 > > > > +00000840: 00 00 00 40 00 00 ed 03 10 80 00 00 00 00 00 00 > ^^ ^^ ^^ > > > > -00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80 > > > > +00000850: bc 42 42 01 31 00 00 00 2d 0d 00 80 00 78 00 00 > ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ > > > > > -00000860: b8 01 ca 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > +00000860: 55 1b 04 00 00 04 00 00 00 00 33 46 10 30 05 00 > ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ > > > > > -00000870: 00 00 00 00 00 00 00 00 7e 05 7e 05 88 45 a2 06 > > > > +00000870: 28 18 04 00 04 06 00 00 41 02 41 02 ec 45 87 07 > ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ > > > > > -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 f4 01 7f 00 > > > > +00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 31 00 16 00 > ^^ ^^ ^^ ^^ ^^ ^^ ^^ > > > > > -00000890: 24 f4 03 40 30 70 30 70 fb 0c 2d 02 58 01 7b 05 > > > > +00000890: 24 f4 03 40 30 70 30 70 e7 10 e3 00 00 00 63 00 > ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ > > Not publicly documented registers that indicate different > "detections" or, in the + case, that the microcontroller or hardware is > not done with calculations. > > > > > > -000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 0f > > > > +000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f > ^^ ^^ > DBX to channel 2, channel 1 phase delayed, 2 samples of delay (in the > '+' case) > Dematrix BTSC force mono (vs unset in the '-' case) > > Those look really odd. I'm not up on Dolby stereo though. > > > > > > -00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 54 > > > > -00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00 > > > > +00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 3d > > > > +00000950: 00 00 00 d2 01 10 40 07 00 08 02 ff 00 00 00 00 > > > > > > > > -00000990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > -000009a0: 00 00 00 00 00 00 00 00 00 00 00 00 21 06 00 00 > > > > +00000990: 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 > > > > +000009a0: 00 00 00 00 00 00 00 00 11 00 00 00 06 f4 00 80 > > (Skipping the 0x900's for now). > > >From what I can tell, what may be going on at initialization is that the > audio microcontroller may be claiming to understand the video standard > before there is actually a video signal present and proceeeding to look > for the audio and configure for it. It is conceivable that once video > locks in, the configuration made by the audio controller may be wrong. > > > > > > > -- SECOND CARD -- > > > > > > > > -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11 > > > > +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11 > > > > > > > > -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 81 01 00 > > > > -00000410: bb 01 ff ff 00 80 00 00 00 00 00 00 00 00 08 00 > > > > +00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 15 00 > > > > +00000410: bb 03 ff ff 00 80 00 00 00 00 00 00 00 00 08 00 > > > > > > > > -00000480: 26 00 00 00 00 00 10 40 10 59 24 f8 dc 40 10 00 > > > > +00000480: 5b 00 00 00 00 00 64 42 17 5c 28 f8 dc 40 10 00 > > > > > > > > -00000800: fe 3f 03 13 fe ff 8d 00 f6 04 01 00 00 00 00 20 > > > > -00000810: 00 02 ff 80 05 09 14 20 c0 31 00 00 50 00 6b 53 > > > > -00000820: 02 55 ce 1b 84 e0 04 e0 a0 01 00 00 e9 01 ed 03 > > > > +00000800: fe 3f 03 13 fe ff 8d 00 f6 04 11 00 00 00 00 a0 > > > > +00000810: 00 02 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47 > > > > +00000820: 53 44 ce 1b 04 e0 04 e0 a0 01 00 00 e9 01 ed 03 > > > > > > > > -00000840: 00 00 00 00 00 00 ed 03 10 80 84 1e 00 00 00 00 > > > > -00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80 > > > > -00000860: b8 01 ca 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > -00000870: 00 00 00 00 00 00 00 00 c0 16 c0 16 88 45 a2 06 > > > > -00000880: da 07 3c 0b bd 83 71 41 23 a4 23 a4 cd 05 dc 04 > > > > -00000890: a9 9b 03 40 59 ae 59 ae c3 0c 52 01 87 06 58 0e > > > > +00000840: 00 00 00 00 00 00 ed 03 10 80 00 00 00 00 00 00 > > > > +00000850: bc 42 42 01 31 00 00 00 b5 12 00 80 00 78 00 00 > > > > +00000860: 55 1b 04 18 00 04 00 00 00 00 33 46 10 30 05 00 > > > > +00000870: 28 18 04 00 04 06 00 00 07 08 07 08 ec 45 87 07 > > > > +00000880: 71 0a 80 0c bd 83 71 41 23 a4 23 a4 16 00 05 00 > > > > +00000890: a9 9b 03 40 59 ae 59 ae f8 08 80 00 00 00 db 03 > > > > > > > > -000008c0: 00 00 00 00 00 00 00 00 1f 06 01 00 00 00 00 0f > > > > +000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f > > > > > > > > -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 > > > > > > > > -00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 a0 > > > > -00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00 > > > > +00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 47 > > > > +00000950: 00 00 00 b0 02 10 40 07 00 08 02 ff 00 00 00 00 > > > > > > > > -000009a0: 00 00 00 00 00 00 00 00 00 00 00 00 e7 06 00 00 > > > > +000009a0: 00 00 00 00 00 00 00 00 11 00 00 00 0a f4 00 80 > > > > And here it is after running a few hours, seems it can go into > > that state during capture too... > > > > 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F > > -00000800: fe 3f 90 13 00 0f 8d 20 f6 04 11 00 00 00 1c e0 > > +00000800: fe 3f f9 13 00 0f 8d 00 f6 04 11 00 00 00 1c e0 > ^^ ^^ > | | > uController DL port-+ + Doesn't matter > > Neither of these should matter. I'm not sure the behavior of the DL > port register when not in memory map mode - as it is now. > > > > 00000810: 00 01 ff 8e 05 09 14 20 c0 31 00 00 d1 05 80 47 > > -00000820: 00 28 00 80 44 e5 84 e5 a8 5c 72 00 f2 07 01 24 > > +00000820: 00 28 00 80 44 e0 84 e0 a8 5c 72 00 f2 07 01 24 > ^^ ^^ > It makes sense that these would get set similarly. These might be a > clue as to why the audio sounds bad. (If it were unmuted - see > below.) > > > > -00000830: 21 a0 86 01 d6 10 00 c0 00 08 01 24 21 a0 86 01 > > +00000830: 21 a0 86 01 00 00 00 40 00 08 01 24 21 a0 86 01 > ^^^^^^^^^^^ > > -00000840: d7 6e 00 c0 00 1b 00 01 31 00 00 00 a6 02 00 80 > > +00000840: 00 00 00 40 00 1b 00 01 31 00 00 00 00 00 00 00 > ^^^^^^^^^^^ ^^^^^^^^^^^ > These register differences don't matter unless the first 3 bytes in each > stay 0 for a long time. By the time the audio controller decides to > unmute, I suspect these should be non-zero. > > > > > -00000850: bc 42 42 01 31 00 00 00 d2 37 00 80 00 78 00 00 > > +00000850: 53 44 42 01 31 00 00 00 cb 0e 00 80 00 78 00 00 > ^^^^^ ^^^^^ > The input waveform changed by about 2.4% - or it didn't, but the audio > microcontroller thought it did, or is converging onto some solution.. > > > > 00000860: 55 1b 04 00 00 04 00 00 00 00 33 46 10 30 05 00 > > 00000870: 28 18 04 00 04 06 00 00 41 02 41 02 ec 45 87 07 > > -00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 00 00 00 00 > > +00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 00 00 04 00 > ^^ > > -00000890: 24 f4 03 40 30 70 30 70 1c 11 f9 00 00 00 7b 00 > > +00000890: 24 f4 03 40 30 70 30 70 22 11 ed 00 00 00 36 00 > ^^ ^^ ^^ > These indicate some difference in advanced decoding of the audio. I'm > not sure they inidcate much. > > > > 000008a0: 78 06 d6 12 87 51 00 00 de 53 03 00 b1 01 00 00 > > 000008b0: d0 f3 00 00 00 00 00 00 c8 00 ff 0f 1f 00 0f 00 > > 000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f > > -000008d0: 70 38 06 01 24 00 ff 7f 00 18 18 18 a3 33 ff 7f > > +000008d0: 70 38 06 1f 24 00 ff 7f 00 18 18 18 a3 33 ff 7f > ^^ > PATH1 Mute control is set to mute everything. This indicates the audio > microcontroller hasn't finished it's work yet at the time of this > snapshot, as it hasn't unmuted things. > > > > Figure this is interesting in comparison the the previous > > when starting up, looks yet a little different in the audio > > register regions. > > Well it is interesting in that you caught the audio controller in the > midst of a change, before it finished some computations and before it > decided to unmute the audio. > > > I'm trying to think of what actions can be taken on the Linux driver end > to ensure the integrity of the microcontroller code and operation, and > the integrity of the SIF signal from the tuner. > > > a) I have code in the cx18 driver that verifies the microcontroller code > load by reading it back and comparing. I can port that back to the > cx25840 driver to give a log indication that the download to the > microcontoller was OK or not. > > b) if the board is wired up so that the IRQ_N pin of the CX25843 goes to > the CX23416 where it can detect and interrupt line, then could detect > the audio microcontroller events indicated in register 0x813 and take > action on some of them: > > RDS interrupt asserted (asserted in dump above) > NICAM bit error rate too high interrupt asserted > NICAM lost lock interrupt asserted > IF signal lost interrupt asserted > Format detection loop complete interrupt asserted (asserted in dump above) > Audio format change interrupt asserted (asserted in dump above) > Audio mode change interrupt asserted (asserted in dump above) > AC97 interrupt asserted > > we could also do the same for the Video interrupts in registers > 0x410-0x411 and reset the audio microcontroller when we see video the > format, present, and/or lock status change. That way the audio > autodetection would work on a stable signal. > > > c) Maybe experiment with the audio automatic gain control settings in > registers 0x814-0x817. > > > I have no idea what about the new kernel has caused symptoms to appear, > so b) and c) are really work-arounds for something else. > > > I'm trying to reproduce the issue with a DTV STB feeding my PVR-150MCE > on Channel 3 with a 2.6.27.30-170.2.82.fc10.x86_64 kernel. So far, no > luck. > > Any ideas?
I've changed my script to not do anything but log the oddity, so I can see the pattern and catch one with bad audio. I'm curious if it stays bad or fixes itself, since in the past day out of 4 interfaces there have been 2 instances of it seeing the lang2 subchannel (and not fully sure the audio was really bad, maybe that happens only some of the time when that subchannel appears). Also I'm figuring that for each input there may be a different sign it's bad, not sure if every signal will show lang2 when it's bad, sure some signals show stereo usually instead of mono like mine. So I'll see what it shows over the next couple days and try to catch a bad audio case and confirm it before doing the register dump on it. Also interested in seeing if there's cases where it sees the subchannel show up, how long that lasts exactly, or if it stays always till I reset it. 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. Thanks, Chris > > Regards, > Andy > > > Thanks, > > Chris > > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- Chris Kennedy [email protected] _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
