Mailing List Archive

On Fri, 2009-08-28 at 12:01 -0500, Chris Kennedy wrote:
> I had an odd experience with ivtv driver setup in
> kernel 2.6.30.4. This is not using myth but just reading
> from the capture cards and manual setup using v4l2-ctl
> and ivtv-tune. The audio on one input of a pvr-500
> sounded really horrible, like far away in the background
> and ringing. I saw on the v4l2-ctl --all output that
> it said 'Available subchannels: mono lang2', different
> than all the other inputs saying just mono. Upon capture
> restart and normal setting up of the card (changing input
> to input 0 or Tuner 0) it didn't fix it. It did fix it
> when I ran the command '/opt/ivtv/v4l2-ctl -d /dev/video2
> --set-audio-input 0'.
>
> I ran kernel 2.6.29.1 for months without ever seeing this problem,
> so not sure if it's a very rare fluke or it'll happen more with this
> newer kernel (which I just started running a few days ago).
>
> I guess this is the 'tinny audio bug', although I've never
> seen this until now, and didn't ever see anyone notice the
> mono/lang2 oddity either.

It sure sounds like it.

My guesses on the tinny audio failure mechanism are

a) the audio microcontroller in the CX25843 is misdetecting the standard
(or some parameters about it) and setting registers wrong. Maybe this
is caused by SIF audio settings or audio AGC setting in the frontend not
being quite right. Though last I checked, I thought the cx25840 driver
was setting things up properly.

b) Firmware is not getting loaded to the audio microcontroller properly
- one or more bytes may be in error. Maybe this could be explain kernel
dependence of symptoms.

c) For 32 ksps tuner audio, the CX25843 AUX_PLL is being run out of spec
at about 196 MHz; 4 MHz below the 200 MHz specified as the lower end of
operation in the CX2584[0123] datasheet. Avoid using 32 ksps audio.


With the death of OTA analog in the US, I have no opportunities to
reproduce this issue.

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...

> It happened twice now, and the second time after setting the
> audio input to 0 on each capture start, so that doesn't fix
> it for good. The difference between a good input and bad input
> is the following from the v4l2-ctl --all cmd...
>
> Good - Available subchannels: mono
> Bad + Available subchannels: mono lang2

I wonder why stereo doesn't show up...

Regards,
Andy


> Thanks,
> Chris
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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.

>
> > Good - Available subchannels: mono
> > Bad + Available subchannels: mono lang2
>
> I wonder why stereo doesn't show up...

It has once since I have been running my check script,
on one interface (have 4, or 2 pvr500's). It went away
when running the v4l2-ctl command and setting the audio
input to 0. The input is a directv tuner box.

Thanks,
Chris
>
> Regards,
> Andy
>
>
> > Thanks,
> > Chris
> >
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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).

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).

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

-00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 00 00
-00000410: bf 01 ff 7f 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 81 35 00
+00000410: bf 07 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00

-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

-00000800: fe 3f 02 13 fe ff 8d 00 f6 04 01 00 00 00 1c 60
-00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 53 47
-00000820: 16 4a ce 1b 85 e0 05 8a a0 01 00 00 e9 01 ed 03
+00000800: fe 3f f8 13 fe ff 8d 00 f6 04 11 00 00 00 1c e0
+00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47
+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
-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 7e 05 7e 05 88 45 a2 06
-00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 f4 01 7f 00
-00000890: 24 f4 03 40 30 70 30 70 fb 0c 2d 02 58 01 7b 05
+00000840: 00 00 00 40 00 00 ed 03 10 80 00 00 00 00 00 00
+00000850: bc 42 42 01 31 00 00 00 2d 0d 00 80 00 78 00 00
+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 31 00 16 00
+00000890: 24 f4 03 40 30 70 30 70 e7 10 e3 00 00 00 63 00

-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

-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

-- 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



Thanks,
Chris
>
> >
> > > Good - Available subchannels: mono
> > > Bad + Available subchannels: mono lang2
> >
> > I wonder why stereo doesn't show up...
>
> It has once since I have been running my check script,
> on one interface (have 4, or 2 pvr500's). It went away
> when running the v4l2-ctl command and setting the audio
> input to 0. The input is a directv tuner box.
>
> Thanks,
> Chris
> >
> > Regards,
> > Andy
> >
> >
> > > Thanks,
> > > Chris
> > >
> >
> >
> > _______________________________________________
> > ivtv-devel mailing list
> > ivtv-devel@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
> --
> Chris Kennedy
> ivtv@groovy.org
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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
>
> -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 00 00
> -00000410: bf 01 ff 7f 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 81 35 00
> +00000410: bf 07 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00
>
> -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
>
> -00000800: fe 3f 02 13 fe ff 8d 00 f6 04 01 00 00 00 1c 60
> -00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 53 47
> -00000820: 16 4a ce 1b 85 e0 05 8a a0 01 00 00 e9 01 ed 03
> +00000800: fe 3f f8 13 fe ff 8d 00 f6 04 11 00 00 00 1c e0
> +00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47
> +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
> -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 7e 05 7e 05 88 45 a2 06
> -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 f4 01 7f 00
> -00000890: 24 f4 03 40 30 70 30 70 fb 0c 2d 02 58 01 7b 05
> +00000840: 00 00 00 40 00 00 ed 03 10 80 00 00 00 00 00 00
> +00000850: bc 42 42 01 31 00 00 00 2d 0d 00 80 00 78 00 00
> +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 31 00 16 00
> +00000890: 24 f4 03 40 30 70 30 70 e7 10 e3 00 00 00 63 00
>
> -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
>
> -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
>
> -- 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
>
>
>
> Thanks,
> Chris
> >
> > >
> > > > Good - Available subchannels: mono
> > > > Bad + Available subchannels: mono lang2
> > >
> > > I wonder why stereo doesn't show up...
> >
> > It has once since I have been running my check script,
> > on one interface (have 4, or 2 pvr500's). It went away
> > when running the v4l2-ctl command and setting the audio
> > input to 0. The input is a directv tuner box.
> >
> > Thanks,
> > Chris
> > >
> > > Regards,
> > > Andy
> > >
> > >
> > > > Thanks,
> > > > Chris
> > > >
> > >
> > >
> > > _______________________________________________
> > > ivtv-devel mailing list
> > > ivtv-devel@ivtvdriver.org
> > > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> >
> > --
> > Chris Kennedy
> > ivtv@groovy.org
> >
> > _______________________________________________
> > ivtv-devel mailing list
> > ivtv-devel@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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
> >
> > -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 00 00
> > -00000410: bf 01 ff 7f 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 81 35 00
> > +00000410: bf 07 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00
> >
> > -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
> >
> > -00000800: fe 3f 02 13 fe ff 8d 00 f6 04 01 00 00 00 1c 60
> > -00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 53 47
> > -00000820: 16 4a ce 1b 85 e0 05 8a a0 01 00 00 e9 01 ed 03
> > +00000800: fe 3f f8 13 fe ff 8d 00 f6 04 11 00 00 00 1c e0
> > +00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47
> > +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
> > -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 7e 05 7e 05 88 45 a2 06
> > -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 f4 01 7f 00
> > -00000890: 24 f4 03 40 30 70 30 70 fb 0c 2d 02 58 01 7b 05
> > +00000840: 00 00 00 40 00 00 ed 03 10 80 00 00 00 00 00 00
> > +00000850: bc 42 42 01 31 00 00 00 2d 0d 00 80 00 78 00 00
> > +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 31 00 16 00
> > +00000890: 24 f4 03 40 30 70 30 70 e7 10 e3 00 00 00 63 00
> >
> > -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
> >
> > -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
> >
> > -- 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
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
-00000830: 21 a0 86 01 d6 10 00 c0 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
-00000850: bc 42 42 01 31 00 00 00 d2 37 00 80 00 78 00 00
+00000820: 00 28 00 80 44 e0 84 e0 a8 5c 72 00 f2 07 01 24
+00000830: 21 a0 86 01 00 00 00 40 00 08 01 24 21 a0 86 01
+00000840: 00 00 00 40 00 1b 00 01 31 00 00 00 00 00 00 00
+00000850: 53 44 42 01 31 00 00 00 cb 0e 00 80 00 78 00 00
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
-00000890: 24 f4 03 40 30 70 30 70 1c 11 f9 00 00 00 7b 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 22 11 ed 00 00 00 36 00
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

Figure this is interesting in comparison the the previous
when starting up, looks yet a little different in the audio
register regions.

Thanks,
Chris

> >
> >
> >
> > Thanks,
> > Chris
> > >
> > > >
> > > > > Good - Available subchannels: mono
> > > > > Bad + Available subchannels: mono lang2
> > > >
> > > > I wonder why stereo doesn't show up...
> > >
> > > It has once since I have been running my check script,
> > > on one interface (have 4, or 2 pvr500's). It went away
> > > when running the v4l2-ctl command and setting the audio
> > > input to 0. The input is a directv tuner box.
> > >
> > > Thanks,
> > > Chris
> > > >
> > > > Regards,
> > > > Andy
> > > >
> > > >
> > > > > Thanks,
> > > > > Chris
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > ivtv-devel mailing list
> > > > ivtv-devel@ivtvdriver.org
> > > > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> > >
> > > --
> > > Chris Kennedy
> > > ivtv@groovy.org
> > >
> > > _______________________________________________
> > > ivtv-devel mailing list
> > > ivtv-devel@ivtvdriver.org
> > > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> >
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, 2009-08-29 at 01:04 -0500, Chris Kennedy wrote:

> 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
> 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
> -00000830: 21 a0 86 01 d6 10 00 c0 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
> -00000850: bc 42 42 01 31 00 00 00 d2 37 00 80 00 78 00 00
> +00000820: 00 28 00 80 44 e0 84 e0 a8 5c 72 00 f2 07 01 24
> +00000830: 21 a0 86 01 00 00 00 40 00 08 01 24 21 a0 86 01
> +00000840: 00 00 00 40 00 1b 00 01 31 00 00 00 00 00 00 00
> +00000850: 53 44 42 01 31 00 00 00 cb 0e 00 80 00 78 00 00
> 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
> -00000890: 24 f4 03 40 30 70 30 70 1c 11 f9 00 00 00 7b 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 22 11 ed 00 00 00 36 00
> 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
>
> Figure this is interesting in comparison the the previous
> when starting up, looks yet a little different in the audio
> register regions.

Could you also send the register differences in the 0x900 region? IIRC
some of them are not AC'97 related and may matter.

I've got some errands to run today (kid birthday party, etc.), so I
won't get to this 'till tonight.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, Aug 29, 2009 at 09:04:48AM -0400, Andy Walls wrote:
> On Sat, 2009-08-29 at 01:04 -0500, Chris Kennedy wrote:
>
> > 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
> > 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
> > -00000830: 21 a0 86 01 d6 10 00 c0 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
> > -00000850: bc 42 42 01 31 00 00 00 d2 37 00 80 00 78 00 00
> > +00000820: 00 28 00 80 44 e0 84 e0 a8 5c 72 00 f2 07 01 24
> > +00000830: 21 a0 86 01 00 00 00 40 00 08 01 24 21 a0 86 01
> > +00000840: 00 00 00 40 00 1b 00 01 31 00 00 00 00 00 00 00
> > +00000850: 53 44 42 01 31 00 00 00 cb 0e 00 80 00 78 00 00
> > 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
> > -00000890: 24 f4 03 40 30 70 30 70 1c 11 f9 00 00 00 7b 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 22 11 ed 00 00 00 36 00
> > 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
> >
> > Figure this is interesting in comparison the the previous
> > when starting up, looks yet a little different in the audio
> > register regions.
>
> Could you also send the register differences in the 0x900 region? IIRC
> some of them are not AC'97 related and may matter.


Here they are...

00000900: aa 4f 01 08 aa 4f 01 08 53 04 01 08 aa 4f 01 08
00000910: c9 00 b0 12 a0 00 00 00 a0 01 00 00 00 00 00 00
00000920: 00 48 3d f5 05 05 00 00 00 00 00 00 00 00 00 00
00000930: 00 00 00 00 00 00 00 00 00 00 00 00 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 c8 01 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 4b
+00000950: 00 00 00 a4 02 10 40 07 00 08 02 ff 00 00 00 00
00000960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000980: 00 00 00 00 00 00 00 00 00 3f 00 3f 00 3f 00 3f
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 b9 f5 00 80
+000009a0: 00 00 00 00 00 00 00 00 11 00 00 00 a2 f6 00 80


Thanks,
Chris
>
> I've got some errands to run today (kid birthday party, etc.), so I
> won't get to this 'till tonight.
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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?

Regards,
Andy

> Thanks,
> Chris



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Hi,

I'm throwing in my comments here as this discussion seems relevant for my
problem. I too experience a tinny audio problem with my PVR-150 card. I've
seen this both with FM audio and line in. The problem is that the audio
becomes distorted when I start a new capture about 15% of the time. It
sounds like there is a high pitched or white noice on top of the ordinary
audio signal. This remains there until I run v4l2-ctl --set-audio-input 1
(or 0 in case I'm using FM tuner). I spent most of yesterday digging into
this problem and I'd like to share my findings in case they could be
helpful, or in case someone has any comments on them.

* Firstly I've noticed that at the beginning of almost every capture there
is a very short glitch in the audio (about one second). When the audio works
fine this distortion goes away as said after about a second, when the audio
goes to the bad state the sound gets gradually worse for 3-4 seconds then
stays bad until --set-audio-input 1 is called. Running --set-audio-input
before the situation is stable does not seem to work (not very thoroughly
tested though). The amount of noise in the stable error condition changes a
bit from time to time.

* Some experimentation shows that it is the last function call in
ivtv_audio_set_io that makes the problem go away:
ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0);
As I understand it this maps to cx25480_s_audio_routing. I've had little
luck figuring out which part of this function (and the stuff it calls)
actually fixes the problem, because disabling parts of it tends to return in
no audio whatsoever.

* I tried changing the driver so that ivtv_audio_set_io is called each time
a capture is started (by disabling the check for unchanged input in
ivtv_s_input), however this does not seem to solve the problem

* Looking at the audio registers using v4l2-dbg I found some interresting
differences:
--- registers-ok2 2009-09-01 16:25:59.774303146 +0200
+++ registers-fail 2009-09-01 16:23:47.232906508 +0200
@@ -64,8 +64,8 @@
Register 0x000008ef = 7fh (127d 01111111b)
Register 0x000008f0 = fch (252d 11111100b)
Register 0x000008f1 = ah (10d 00001010b)
-Register 0x000008f2 = 0h (0d 00000000b)
-Register 0x000008f3 = 88h (136d 10001000b)
+Register 0x000008f2 = 50h (80d 01010000b)
+Register 0x000008f3 = 99h (153d 10011001b)
Register 0x000008f4 = 88h (136d 10001000b)
Register 0x000008f5 = 88h (136d 10001000b)
Register 0x000008f6 = 55h (85d 01010101b)

I am not able to comprehend what these registers are about from the
datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff
to these registers resets them to the value they have in the OK state, but
it does not affect the problem. My gutfeeling say it could be related to
enabling audio output from the cx25843 before enabling reception in the ivtv
chip and that some timing issue makes sure it only some times actually
overflows the fifo.


Best regards

Sigmund Augdal


On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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.
>
> Regards,
> Andy
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>

On Wed, Sep 2, 2009 at 11:46 AM, Sigmund Augdal <sigmund@snap.tv> wrote:

> Hi,
>
> I'm throwing in my comments here as this discussion seems relevant for my
> problem. I too experience a tinny audio problem with my PVR-150 card. I've
> seen this both with FM audio and line in. The problem is that the audio
> becomes distorted when I start a new capture about 15% of the time. It
> sounds like there is a high pitched or white noice on top of the ordinary
> audio signal. This remains there until I run v4l2-ctl --set-audio-input 1
> (or 0 in case I'm using FM tuner). I spent most of yesterday digging into
> this problem and I'd like to share my findings in case they could be
> helpful, or in case someone has any comments on them.
>
> * Firstly I've noticed that at the beginning of almost every capture there
> is a very short glitch in the audio (about one second). When the audio works
> fine this distortion goes away as said after about a second, when the audio
> goes to the bad state the sound gets gradually worse for 3-4 seconds then
> stays bad until --set-audio-input 1 is called. Running --set-audio-input
> before the situation is stable does not seem to work (not very thoroughly
> tested though). The amount of noise in the stable error condition changes a
> bit from time to time.
>
> * Some experimentation shows that it is the last function call in
> ivtv_audio_set_io that makes the problem go away:
> ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0);
> As I understand it this maps to cx25480_s_audio_routing. I've had little
> luck figuring out which part of this function (and the stuff it calls)
> actually fixes the problem, because disabling parts of it tends to return in
> no audio whatsoever.
>
> * I tried changing the driver so that ivtv_audio_set_io is called each time
> a capture is started (by disabling the check for unchanged input in
> ivtv_s_input), however this does not seem to solve the problem
>
> * Looking at the audio registers using v4l2-dbg I found some interresting
> differences:
> --- registers-ok2 2009-09-01 16:25:59.774303146 +0200
> +++ registers-fail 2009-09-01 16:23:47.232906508 +0200
> @@ -64,8 +64,8 @@
> Register 0x000008ef = 7fh (127d 01111111b)
> Register 0x000008f0 = fch (252d 11111100b)
> Register 0x000008f1 = ah (10d 00001010b)
> -Register 0x000008f2 = 0h (0d 00000000b)
> -Register 0x000008f3 = 88h (136d 10001000b)
> +Register 0x000008f2 = 50h (80d 01010000b)
> +Register 0x000008f3 = 99h (153d 10011001b)
> Register 0x000008f4 = 88h (136d 10001000b)
> Register 0x000008f5 = 88h (136d 10001000b)
> Register 0x000008f6 = 55h (85d 01010101b)
>
> I am not able to comprehend what these registers are about from the
> datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff
> to these registers resets them to the value they have in the OK state, but
> it does not affect the problem. My gutfeeling say it could be related to
> enabling audio output from the cx25843 before enabling reception in the ivtv
> chip and that some timing issue makes sure it only some times actually
> overflows the fifo.
>

This simple change seems to remove the problem for me. I still don't know
exactly what the problem is or why this fix works, but it seems to work for
me. It is basically just an automated way of doing the manual workaround.

diff -r 7c23abfe445f linux/drivers/media/video/ivtv/ivtv-streams.c
--- a/linux/drivers/media/video/ivtv/ivtv-streams.c Mon Aug 31 02:03:28 2009
-0300
+++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Sep 02 13:33:58 2009
+0200
@@ -42,6 +42,7 @@
#include "ivtv-yuv.h"
#include "ivtv-cards.h"
#include "ivtv-streams.h"
+#include "ivtv-routing.h"

static const struct v4l2_file_operations ivtv_v4l2_enc_fops = {
.owner = THIS_MODULE,
@@ -599,6 +600,7 @@
else
ivtv_clear_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);

+ ivtv_audio_set_io(itv);
/* you're live! sit back and await interrupts :) */
atomic_inc(&itv->capturing);
return 0;

Best regards

Sigmund Augdal


>
>
> Best regards
>
> Sigmund Augdal
>
>
> On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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.
>>
>> Regards,
>> Andy
>>
>>
>>
>> _______________________________________________
>> ivtv-devel mailing list
>> ivtv-devel@ivtvdriver.org
>> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>>
>
>

On Wed, Sep 02, 2009 at 01:43:28PM +0200, Sigmund Augdal wrote:
> On Wed, Sep 2, 2009 at 11:46 AM, Sigmund Augdal <sigmund@snap.tv> wrote:
>
> > Hi,
> >
> > I'm throwing in my comments here as this discussion seems relevant for my
> > problem. I too experience a tinny audio problem with my PVR-150 card. I've
> > seen this both with FM audio and line in. The problem is that the audio
> > becomes distorted when I start a new capture about 15% of the time. It
> > sounds like there is a high pitched or white noice on top of the ordinary
> > audio signal. This remains there until I run v4l2-ctl --set-audio-input 1
> > (or 0 in case I'm using FM tuner). I spent most of yesterday digging into
> > this problem and I'd like to share my findings in case they could be
> > helpful, or in case someone has any comments on them.
> >
> > * Firstly I've noticed that at the beginning of almost every capture there
> > is a very short glitch in the audio (about one second). When the audio works
> > fine this distortion goes away as said after about a second, when the audio
> > goes to the bad state the sound gets gradually worse for 3-4 seconds then
> > stays bad until --set-audio-input 1 is called. Running --set-audio-input
> > before the situation is stable does not seem to work (not very thoroughly
> > tested though). The amount of noise in the stable error condition changes a
> > bit from time to time.
> >
> > * Some experimentation shows that it is the last function call in
> > ivtv_audio_set_io that makes the problem go away:
> > ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0);
> > As I understand it this maps to cx25480_s_audio_routing. I've had little
> > luck figuring out which part of this function (and the stuff it calls)
> > actually fixes the problem, because disabling parts of it tends to return in
> > no audio whatsoever.
> >
> > * I tried changing the driver so that ivtv_audio_set_io is called each time
> > a capture is started (by disabling the check for unchanged input in
> > ivtv_s_input), however this does not seem to solve the problem
> >
> > * Looking at the audio registers using v4l2-dbg I found some interresting
> > differences:
> > --- registers-ok2 2009-09-01 16:25:59.774303146 +0200
> > +++ registers-fail 2009-09-01 16:23:47.232906508 +0200
> > @@ -64,8 +64,8 @@
> > Register 0x000008ef = 7fh (127d 01111111b)
> > Register 0x000008f0 = fch (252d 11111100b)
> > Register 0x000008f1 = ah (10d 00001010b)
> > -Register 0x000008f2 = 0h (0d 00000000b)
> > -Register 0x000008f3 = 88h (136d 10001000b)
> > +Register 0x000008f2 = 50h (80d 01010000b)
> > +Register 0x000008f3 = 99h (153d 10011001b)
> > Register 0x000008f4 = 88h (136d 10001000b)
> > Register 0x000008f5 = 88h (136d 10001000b)
> > Register 0x000008f6 = 55h (85d 01010101b)
> >
> > I am not able to comprehend what these registers are about from the
> > datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff
> > to these registers resets them to the value they have in the OK state, but
> > it does not affect the problem. My gutfeeling say it could be related to
> > enabling audio output from the cx25843 before enabling reception in the ivtv
> > chip and that some timing issue makes sure it only some times actually
> > overflows the fifo.
> >
>
> This simple change seems to remove the problem for me. I still don't know
> exactly what the problem is or why this fix works, but it seems to work for
> me. It is basically just an automated way of doing the manual workaround.
>
> diff -r 7c23abfe445f linux/drivers/media/video/ivtv/ivtv-streams.c
> --- a/linux/drivers/media/video/ivtv/ivtv-streams.c Mon Aug 31 02:03:28 2009
> -0300
> +++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Sep 02 13:33:58 2009
> +0200
> @@ -42,6 +42,7 @@
> #include "ivtv-yuv.h"
> #include "ivtv-cards.h"
> #include "ivtv-streams.h"
> +#include "ivtv-routing.h"
>
> static const struct v4l2_file_operations ivtv_v4l2_enc_fops = {
> .owner = THIS_MODULE,
> @@ -599,6 +600,7 @@
> else
> ivtv_clear_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);
>
> + ivtv_audio_set_io(itv);
> /* you're live! sit back and await interrupts :) */
> atomic_inc(&itv->capturing);
> return 0;
>
> Best regards
>
> Sigmund Augdal
>
>
> >
> >
> > Best regards
> >
> > Sigmund Augdal
> >
> >
> > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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
> >>
> >> Regards,
> >> Andy
> >>
> >>
> >>
> >> _______________________________________________
> >> ivtv-devel mailing list
> >> ivtv-devel@ivtvdriver.org
> >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> >>
> >
> >

> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel


--
Chris Kennedy
ivtv@groovy.org

On Wed, Sep 02, 2009 at 01:43:28PM +0200, Sigmund Augdal wrote:
> On Wed, Sep 2, 2009 at 11:46 AM, Sigmund Augdal <sigmund@snap.tv> wrote:
>
> > Hi,
> >
> > I'm throwing in my comments here as this discussion seems relevant for my
> > problem. I too experience a tinny audio problem with my PVR-150 card. I've
> > seen this both with FM audio and line in. The problem is that the audio
> > becomes distorted when I start a new capture about 15% of the time. It
> > sounds like there is a high pitched or white noice on top of the ordinary
> > audio signal. This remains there until I run v4l2-ctl --set-audio-input 1
> > (or 0 in case I'm using FM tuner). I spent most of yesterday digging into
> > this problem and I'd like to share my findings in case they could be
> > helpful, or in case someone has any comments on them.
> >
> > * Firstly I've noticed that at the beginning of almost every capture there
> > is a very short glitch in the audio (about one second). When the audio works
> > fine this distortion goes away as said after about a second, when the audio
> > goes to the bad state the sound gets gradually worse for 3-4 seconds then
> > stays bad until --set-audio-input 1 is called. Running --set-audio-input
> > before the situation is stable does not seem to work (not very thoroughly
> > tested though). The amount of noise in the stable error condition changes a
> > bit from time to time.
> >
> > * Some experimentation shows that it is the last function call in
> > ivtv_audio_set_io that makes the problem go away:
> > ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0);
> > As I understand it this maps to cx25480_s_audio_routing. I've had little
> > luck figuring out which part of this function (and the stuff it calls)
> > actually fixes the problem, because disabling parts of it tends to return in
> > no audio whatsoever.
> >
> > * I tried changing the driver so that ivtv_audio_set_io is called each time
> > a capture is started (by disabling the check for unchanged input in
> > ivtv_s_input), however this does not seem to solve the problem
> >
> > * Looking at the audio registers using v4l2-dbg I found some interresting
> > differences:
> > --- registers-ok2 2009-09-01 16:25:59.774303146 +0200
> > +++ registers-fail 2009-09-01 16:23:47.232906508 +0200
> > @@ -64,8 +64,8 @@
> > Register 0x000008ef = 7fh (127d 01111111b)
> > Register 0x000008f0 = fch (252d 11111100b)
> > Register 0x000008f1 = ah (10d 00001010b)
> > -Register 0x000008f2 = 0h (0d 00000000b)
> > -Register 0x000008f3 = 88h (136d 10001000b)
> > +Register 0x000008f2 = 50h (80d 01010000b)
> > +Register 0x000008f3 = 99h (153d 10011001b)
> > Register 0x000008f4 = 88h (136d 10001000b)
> > Register 0x000008f5 = 88h (136d 10001000b)
> > Register 0x000008f6 = 55h (85d 01010101b)
> >
> > I am not able to comprehend what these registers are about from the
> > datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff
> > to these registers resets them to the value they have in the OK state, but
> > it does not affect the problem. My gutfeeling say it could be related to
> > enabling audio output from the cx25843 before enabling reception in the ivtv
> > chip and that some timing issue makes sure it only some times actually
> > overflows the fifo.
> >
>
> This simple change seems to remove the problem for me. I still don't know
> exactly what the problem is or why this fix works, but it seems to work for
> me. It is basically just an automated way of doing the manual workaround.
>
> diff -r 7c23abfe445f linux/drivers/media/video/ivtv/ivtv-streams.c
> --- a/linux/drivers/media/video/ivtv/ivtv-streams.c Mon Aug 31 02:03:28 2009
> -0300
> +++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Sep 02 13:33:58 2009
> +0200
> @@ -42,6 +42,7 @@
> #include "ivtv-yuv.h"
> #include "ivtv-cards.h"
> #include "ivtv-streams.h"
> +#include "ivtv-routing.h"
>
> static const struct v4l2_file_operations ivtv_v4l2_enc_fops = {
> .owner = THIS_MODULE,
> @@ -599,6 +600,7 @@
> else
> ivtv_clear_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);
>
> + ivtv_audio_set_io(itv);
> /* you're live! sit back and await interrupts :) */
> atomic_inc(&itv->capturing);
> return 0;
>

Does it fix the audio for you when putting that a little higher
up where the digitizer is initialized? Like this....

if (atomic_read(&itv->capturing) == 0) {
/* Clear all Pending Interrupts */
ivtv_set_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);

clear_bit(IVTV_F_I_EOS, &itv->i_flags);

/* Initialize Digitizer for Capture */
v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
ivtv_msleep_timeout(300, 1);
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
v4l2_subdev_call(itv->sd_video, video, s_stream, 1);

/* Audio input reset */
ivtv_audio_set_io(itv);
}


Looking at this, it seems it would be more logical to put there (if
it still fixes the issue) because otherwise it would do this each
capture type start up (like when VBI starts or any other types).
I've noticed when resetting the audio input it has a drop in audio
for a half second or so. So this to me would be less intrusive,
just wondering if it works before the capture start command is
given to the firmware and when interrupts are not yet cleared.

I'm going to try this and see if it prevents my audio from getting
tinny. I'm starting to think this really mostly only happens on
capture start, but may rarely happen in the middle of capturing, so
in that case this wouldn't fix it. In that case the things Andy said
about looking for a possible signaling through interrupt from the
chip would be necessary it seems, otherwise an external script like
I'm using.

Also what does your tuner setup look like when it gets tinny,
the output of v4l2-ctl -T? I'm really curious if it's always
the same as I see here, or if it can vary, mine is always this...
"Available subchannels: mono lang2" when bad and no lang2 when good.

Thanks,
Chris
> Best regards
>
> Sigmund Augdal
>
>
> >
> >
> > Best regards
> >
> > Sigmund Augdal
> >
> >
> > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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.
> >>
> >> Regards,
> >> Andy
> >>
> >>
> >>
> >> _______________________________________________
> >> ivtv-devel mailing list
> >> ivtv-devel@ivtvdriver.org
> >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> >>
> >
> >

> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
Chris Kennedy
ivtv@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-09-03 at 15:48 -0500, Chris Kennedy wrote:
> On Wed, Sep 02, 2009 at 01:43:28PM +0200, Sigmund Augdal wrote:
> > On Wed, Sep 2, 2009 at 11:46 AM, Sigmund Augdal <sigmund@snap.tv> wrote:
> >
> > > Hi,
> > >
> > > I'm throwing in my comments here as this discussion seems relevant for my
> > > problem. I too experience a tinny audio problem with my PVR-150 card. I've
> > > seen this both with FM audio and line in. The problem is that the audio
> > > becomes distorted when I start a new capture about 15% of the time. It
> > > sounds like there is a high pitched or white noice on top of the ordinary
> > > audio signal. This remains there until I run v4l2-ctl --set-audio-input 1
> > > (or 0 in case I'm using FM tuner). I spent most of yesterday digging into
> > > this problem and I'd like to share my findings in case they could be
> > > helpful, or in case someone has any comments on them.
> > >
> > > * Firstly I've noticed that at the beginning of almost every capture there
> > > is a very short glitch in the audio (about one second). When the audio works
> > > fine this distortion goes away as said after about a second, when the audio
> > > goes to the bad state the sound gets gradually worse for 3-4 seconds then
> > > stays bad until --set-audio-input 1 is called. Running --set-audio-input
> > > before the situation is stable does not seem to work (not very thoroughly
> > > tested though). The amount of noise in the stable error condition changes a
> > > bit from time to time.
> > >
> > > * Some experimentation shows that it is the last function call in
> > > ivtv_audio_set_io that makes the problem go away:
> > > ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0);
> > > As I understand it this maps to cx25480_s_audio_routing. I've had little
> > > luck figuring out which part of this function (and the stuff it calls)
> > > actually fixes the problem, because disabling parts of it tends to return in
> > > no audio whatsoever.
> > >
> > > * I tried changing the driver so that ivtv_audio_set_io is called each time
> > > a capture is started (by disabling the check for unchanged input in
> > > ivtv_s_input), however this does not seem to solve the problem
> > >
> > > * Looking at the audio registers using v4l2-dbg I found some interresting
> > > differences:
> > > --- registers-ok2 2009-09-01 16:25:59.774303146 +0200
> > > +++ registers-fail 2009-09-01 16:23:47.232906508 +0200
> > > @@ -64,8 +64,8 @@
> > > Register 0x000008ef = 7fh (127d 01111111b)
> > > Register 0x000008f0 = fch (252d 11111100b)
> > > Register 0x000008f1 = ah (10d 00001010b)
> > > -Register 0x000008f2 = 0h (0d 00000000b)
> > > -Register 0x000008f3 = 88h (136d 10001000b)
> > > +Register 0x000008f2 = 50h (80d 01010000b)
> > > +Register 0x000008f3 = 99h (153d 10011001b)
> > > Register 0x000008f4 = 88h (136d 10001000b)
> > > Register 0x000008f5 = 88h (136d 10001000b)
> > > Register 0x000008f6 = 55h (85d 01010101b)
> > >
> > > I am not able to comprehend what these registers are about from the
> > > datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff
> > > to these registers resets them to the value they have in the OK state, but
> > > it does not affect the problem. My gutfeeling say it could be related to
> > > enabling audio output from the cx25843 before enabling reception in the ivtv
> > > chip and that some timing issue makes sure it only some times actually
> > > overflows the fifo.
> > >
> >
> > This simple change seems to remove the problem for me. I still don't know
> > exactly what the problem is or why this fix works, but it seems to work for
> > me. It is basically just an automated way of doing the manual workaround.
> >
> > diff -r 7c23abfe445f linux/drivers/media/video/ivtv/ivtv-streams.c
> > --- a/linux/drivers/media/video/ivtv/ivtv-streams.c Mon Aug 31 02:03:28 2009
> > -0300
> > +++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Sep 02 13:33:58 2009
> > +0200
> > @@ -42,6 +42,7 @@
> > #include "ivtv-yuv.h"
> > #include "ivtv-cards.h"
> > #include "ivtv-streams.h"
> > +#include "ivtv-routing.h"
> >
> > static const struct v4l2_file_operations ivtv_v4l2_enc_fops = {
> > .owner = THIS_MODULE,
> > @@ -599,6 +600,7 @@
> > else
> > ivtv_clear_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);
> >
> > + ivtv_audio_set_io(itv);
> > /* you're live! sit back and await interrupts :) */
> > atomic_inc(&itv->capturing);
> > return 0;
> >
>
> Does it fix the audio for you when putting that a little higher
> up where the digitizer is initialized? Like this....
>
> if (atomic_read(&itv->capturing) == 0) {
> /* Clear all Pending Interrupts */
> ivtv_set_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);
>
> clear_bit(IVTV_F_I_EOS, &itv->i_flags);
>
> /* Initialize Digitizer for Capture */
> v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
> ivtv_msleep_timeout(300, 1);
> ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
> v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
>
> /* Audio input reset */
> ivtv_audio_set_io(itv);
> }
>
>
> Looking at this, it seems it would be more logical to put there (if
> it still fixes the issue) because otherwise it would do this each
> capture type start up (like when VBI starts or any other types).
> I've noticed when resetting the audio input it has a drop in audio
> for a half second or so. So this to me would be less intrusive,
> just wondering if it works before the capture start command is
> given to the firmware and when interrupts are not yet cleared.
>
> I'm going to try this and see if it prevents my audio from getting
> tinny. I'm starting to think this really mostly only happens on
> capture start, but may rarely happen in the middle of capturing, so
> in that case this wouldn't fix it. In that case the things Andy said
> about looking for a possible signaling through interrupt from the
> chip would be necessary it seems, otherwise an external script like
> I'm using.
>
> Also what does your tuner setup look like when it gets tinny,
> the output of v4l2-ctl -T? I'm really curious if it's always
> the same as I see here, or if it can vary, mine is always this...
> "Available subchannels: mono lang2" when bad and no lang2 when good.

I recall Sigmund had mentioned his symptoms happen for Line-in audio and
FM radio. Although FM comes from the tuner it's at AF, so both are via
I2S input, if I'm not mistaken.

Regards,
Andy

> Thanks,
> Chris
> > Best regards
> >
> > Sigmund Augdal
> >
> >
> > >
> > >
> > > Best regards
> > >
> > > Sigmund Augdal
> > >
> > >
> > > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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.
> > >>
> > >> Regards,
> > >> Andy
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> ivtv-devel mailing list
> > >> ivtv-devel@ivtvdriver.org
> > >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> > >>
> > >
> > >
>
> > _______________________________________________
> > ivtv-devel mailing list
> > ivtv-devel@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Wed, 2009-09-02 at 11:46 +0200, Sigmund Augdal wrote:
> Hi,
>
>
>
> I'm throwing in my comments here as this discussion seems relevant for
> my problem. I too experience a tinny audio problem with my PVR-150
> card. I've seen this both with FM audio and line in. The problem is
> that the audio becomes distorted when I start a new capture about 15%
> of the time. It sounds like there is a high pitched or white noice on
> top of the ordinary audio signal. This remains there until I run
> v4l2-ctl --set-audio-input 1 (or 0 in case I'm using FM tuner). I
> spent most of yesterday digging into this problem and I'd like to
> share my findings in case they could be helpful, or in case someone
> has any comments on them.
>
> * Firstly I've noticed that at the beginning of almost every capture
> there is a very short glitch in the audio (about one second). When the
> audio works fine this distortion goes away as said after about a
> second, when the audio goes to the bad state the sound gets gradually
> worse for 3-4 seconds then stays bad until --set-audio-input 1 is
> called. Running --set-audio-input before the situation is stable does
> not seem to work (not very thoroughly tested though). The amount of
> noise in the stable error condition changes a bit from time to time.
>
>
> * Some experimentation shows that it is the last function call in
> ivtv_audio_set_io that makes the problem go away:
> ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input,
> output, 0);
> As I understand it this maps to cx25480_s_audio_routing. I've had
> little luck figuring out which part of this function (and the stuff it
> calls) actually fixes the problem, because disabling parts of it tends
> to return in no audio whatsoever.
>
> * I tried changing the driver so that ivtv_audio_set_io is called each
> time a capture is started (by disabling the check for unchanged input
> in ivtv_s_input), however this does not seem to solve the problem
>
> * Looking at the audio registers using v4l2-dbg I found some
> interresting differences:
> --- registers-ok2 2009-09-01 16:25:59.774303146 +0200
> +++ registers-fail 2009-09-01 16:23:47.232906508 +0200
> @@ -64,8 +64,8 @@
> Register 0x000008ef = 7fh (127d 01111111b)
> Register 0x000008f0 = fch (252d 11111100b)
> Register 0x000008f1 = ah (10d 00001010b)
> -Register 0x000008f2 = 0h (0d 00000000b)
> -Register 0x000008f3 = 88h (136d 10001000b)
> +Register 0x000008f2 = 50h (80d 01010000b)
^^^^

Sample Rate Converter 3 underflowed. See figure 3-38 in the datatsheet.
This is the SRC on the I2S output to the CX23416 chip's I2S input.

If you want a technical background on sample rate converters, I found
Fritz Rothacher (who used to work for Rockwell Semiconductor, now
Conexant), posted his a Ph.D. thesis on Sample rate conversion:

http://www.guest.iis.ee.ethz.ch/~rota/

He also has a patent on effecient sample rate conversion assigned to
Rockwell Semiconductor:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5880980.PN.&OS=PN/5880980&RS=PN/5880980




> +Register 0x000008f3 = 99h (153d 10011001b)
> Register 0x000008f4 = 88h (136d 10001000b)
> Register 0x000008f5 = 88h (136d 10001000b)
> Register 0x000008f6 = 55h (85d 01010101b)
>
> I am not able to comprehend what these registers are about from the
> datasheet, but they seem to indicate some fifo over/underflow. Writing
> 0xff to these registers resets them to the value they have in the OK
> state, but it does not affect the problem. My gutfeeling say it could
> be related to enabling audio output from the cx25843 before enabling
> reception in the ivtv chip and that some timing issue makes sure it
> only some times actually overflows the fifo.

This is all just speculation, but ...

My gut feeling is that, occasionally, bit banged I2C transactions to set
up the CX25843 registers through the CX23416's I2C master are silently
failing. I suspect lspci -vv will show Master or Target Aborts on the
CX23416 or the PCI bridge that the CX23416 is behind.

This appears to be some sort of sample rate conversion, AUX PLL, or I2S
clock divisor set up problem. I suspect doing the audio setup at a time
when the PCI bridges aren't busy gives a better chance of the registers
being set correctly via bit banged I2C.

A brute force check of that hypothesis would be to do a readback of the
registers that are being written by cx25480_audio_set_path(),
input_change(), and set_audclk_freq() to see if they get set to the
intended values. Maybe you can modify cx25840_write(),
cx25840_write4(), and cx25840_and_or() to automatically do the readbacks
by calling cx25840_read() or cx25840_read4() and log any difference.

It may also be the case that the I2S output was not properly set up in
cx25840_initialize(), if registers 0x918 and 0x919 were not successfully
set due to I2C errors.


Regards,
Andy


> Best regards
>
> Sigmund Augdal
>
>
>
> On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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.
>
> Regards,
> Andy
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Wed, 2009-09-02 at 23:25 -0500, Chris Kennedy wrote:

> > > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <awalls@radix.net> 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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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 <awalls@radix.net> 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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-09-10 at 07:23 -0500, Chris Kennedy wrote:

> > Well you can stop until I fix the debug line to print the interrupt
> > status to the log too. I want to know which status bit I need to care
> > about.
>
> Oh I see that line, but just in dmesg and not the logs, here's what
> I'm getting in dmesg at least so you see the normal pattern (seems the
> afc ac97 are the most frequent)...
^^^^

Really, really odd, seeing as we don't configure the AC'97 interface,
nor use it.


> cx25840 0-0044: ... after initial format detection loop completed!
> cx25840 0-0044: Detected audio mode: mono
> cx25840 0-0044: Detected audio standard: BTSC
> cx25840 0-0044: Audio muted: no
> cx25840 0-0044: Audio microcontroller: running
> cx25840 0-0044: Configured audio standard: automatic detection
> cx25840 0-0044: Configured audio system: BTSC
> cx25840 0-0044: Specified audio input: Tuner (In8)
> cx25840 0-0044: Preferred audio mode: stereo
> cx25840 3-0044: Audio status: nber nll ifl fdl afc amc ac97
^^^^^^^^ ^^^

The NICAM (French?) audio status flags seem just plain wrong.

Loosing the SIF (IF Lost: ifl) can't be good in any case.

There are just way too many flags set at once here. Something's screwed
up: either the microcontroller software or the I2C bus maybe?

Also RDS interrupt status isn't set, which my firmware always seems to
have set.


> cx25840 3-0044: Audio mode change occured
> cx25840 3-0044: ... after initial format detection loop completed!
> cx25840 3-0044: Audio format change occured
> cx25840 3-0044: ... after initial format detection loop completed!
> cx25840 3-0044: Audio format detection loop complete
> cx25840 3-0044: Detected audio mode: mono
> cx25840 3-0044: Detected audio standard: BTSC
> cx25840 3-0044: Audio muted: no
> cx25840 3-0044: Audio microcontroller: running
> cx25840 3-0044: Configured audio standard: automatic detection
> cx25840 3-0044: Configured audio system: BTSC
> cx25840 3-0044: Specified audio input: Tuner (In8)
> cx25840 3-0044: Preferred audio mode: stereo
> cx25840 3-0044: Audio status: afc ac97
> cx25840 3-0044: Audio format change occured
> cx25840 3-0044: ... after initial format detection loop completed!
> cx25840 3-0044: Detected audio mode: mono
> cx25840 3-0044: Detected audio standard: BTSC
> cx25840 3-0044: Audio muted: no
> cx25840 3-0044: Audio microcontroller: running
> cx25840 3-0044: Configured audio standard: automatic detection
> cx25840 3-0044: Configured audio system: BTSC
> cx25840 3-0044: Specified audio input: Tuner (In8)
> cx25840 3-0044: Preferred audio mode: stereo
> cx25840 3-0044: Audio status: fdl afc amc ac97
^^^^^^^^^^^^^^^^

Better, but it still seems like too many things are set. Do you have a
long poll interval set?

>
> Is it basically it needs to be logged at the info level instead
> of using that dbg statement, this seems to catch it for me...
>
> /* Debug log on anything other than RDS which is always set apparently*/
> if (v & ~AUD_INT_STAT_RDS)
> if (cx25840_debug >= 3)
> v4l_info(client,
> "Audio status: %s%s%s%s%s%s%s%s\n",
> v & AUD_INT_STAT_RDS ? "rds " : " ",
> v & AUD_INT_STAT_NBER ? "nber " : " ",
> v & AUD_INT_STAT_NLL ? "nll " : " ",
> v & AUD_INT_STAT_IFL ? "ifl " : " ",
> v & AUD_INT_STAT_FDL ? "fdl " : " ",
> v & AUD_INT_STAT_AFC ? "afc " : " ",
> v & AUD_INT_STAT_AMC ? "amc " : " ",
> v & AUD_INT_STAT_AC97 ? "ac97 " : " ");
> //v4l_dbg(3, cx25840_debug, client,
>

Yeah, that's all I was going to do.

Well, collect some data. We'll see what shows up.

I'm not hopeful given the number of flags that are always set in the
log. It really indicates to me something is wrong. I'd guess the
firmware version is not actually right for the CX25843 or the firmware
load is getting corrupted.

When I find the time this weekend, I'll port my firmware load
verification routine from the cx18 driver.

Thanks for all the testing so far.

BTW, here are hashes for the firmwares I have in use on my system:

$ md5sum /lib/firmware/v4l-cx25840.fw /lib/firmware/v4l-cx23418-dig.fw
99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw
b3704908fd058485f3ef136941b2e513 /lib/firmware/v4l-cx23418-dig.fw

Regards,
Andy

>
> Thanks,
> Chris



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Hans,

Andy Walls wrote:
> Here are hashes for the firmwares I have in use on my system:
>
> $ md5sum /lib/firmware/v4l-cx25840.fw /lib/firmware/v4l-cx23418-dig.fw
> 99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw
> b3704908fd058485f3ef136941b2e513 /lib/firmware/v4l-cx23418-dig.fw
>
> Regards,
> Andy

On Thu, 2009-09-10 at 21:09 -0500, Chris Kennedy wrote:
> My checksums are a little odd, because the one of yours for the cx23418
> is the same as my 25840...
>
> b3704908fd058485f3ef136941b2e513 /lib/firmware/v4l-cx25840.fw
> 9b39b3d3bba1ce2da40f82ef0c50ef48 /lib/firmware/v4l-cx2341x-enc.fw
>
> These are the same from the bundle on ivtvdriver.org.


Andy Walls wrote:
>Chris kennedy wrote:
>> cx25840 3-0044: Audio status: nber nll ifl fdl afc amc ac97
> ^^^^^^^^ ^^^
> The NICAM (French?) audio status flags seem just plain wrong.


Given the testing Chris has done with my patches, it looks like using
CX23418 A/V core firmware with a CX25843 is returning non-sensical
cominations of interrupt status flags in the audio interrupt status
register (0x819 IIRC) of the CX25843.

In the above the NICAM related flags don't make sense and neither does
the AC97 status. The (S)IF L(ost) flag makes no sense with the format
detection flags and ormat detetction loop complete flags, etc. Rarely
do I get more than 1 flag other than RDS (which is always set for me).
When I do get multple flags at once, its FDL and AFC (IIRC).

Could you revert the firmware archive to use a known CX2584x specific
firmware for the cx25840 firmware file in the archive at
dl.ivtvdriver.org?

I suspect the CX23418 firmware image being distributed as CX2584x
firmware is causing problems for CX2584x chips.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

> Andy Walls wrote:

> Given the testing Chris has done with my patches, it looks like using
> CX23418 A/V core firmware with a CX25843 is returning non-sensical
> cominations of interrupt status flags in the audio interrupt status
> register (0x819 IIRC) of the CX25843.
>
> In the above the NICAM related flags don't make sense and neither does
> the AC97 status. The (S)IF L(ost) flag makes no sense with the format
> detection flags and ormat detetction loop complete flags, etc. Rarely
> do I get more than 1 flag other than RDS (which is always set for me).
> When I do get multple flags at once, its FDL and AFC (IIRC).
>
> Could you revert the firmware archive to use a known CX2584x specific
> firmware for the cx25840 firmware file in the archive at
> dl.ivtvdriver.org?
>
> I suspect the CX23418 firmware image being distributed as CX2584x
> firmware is causing problems for CX2584x chips.

I'm seeing more and more of this bad audio problem with a PAL PVR150 using
the line input audio and more recent kernel versions (currently Linux
jupiter 2.6.30-gentoo-r4 #2 SMP Thu Aug 13 23:54:02 NZST 2009 x86_64 AMD
Athlon(tm) Dual Core Processor 5050e AuthenticAMD GNU/Linux) and newer
(faster) hardware.

Is there an md5sum that would identify a known good firmware? The files in
the archive are not very well described (dates don't mean much to me). I'm
also a bit confused by the device numbers as my dsmeg quotes both cx23416
and cx25840

This is what I get at startup - very standard Gentoo fare...

Sep 13 12:14:39 jupiter ivtv: Start initialization, version 1.4.1
Sep 13 12:14:39 jupiter ivtv0: Initializing card 0
Sep 13 12:14:39 jupiter ivtv0: Autodetected Hauppauge card (cx23416 based)
Sep 13 12:14:39 jupiter ivtv 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI
17 (level, low) -> IRQ 17
Sep 13 12:14:39 jupiter ivtv0: Unreasonably low latency timer, setting to
64 (was 32)
Sep 13 12:14:39 jupiter ivtv0: Autodetected Hauppauge WinTV PVR-150
Sep 13 12:14:39 jupiter cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c
driver #0)
Sep 13 12:14:39 jupiter tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #0)
Sep 13 12:14:39 jupiter tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Sep 13 12:14:39 jupiter wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
Sep 13 12:14:39 jupiter IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on
shared IRQs
Sep 13 12:14:39 jupiter ivtv0: Registered device video0 for encoder MPG
(4096 kB)
Sep 13 12:14:39 jupiter ivtv0: Registered device video32 for encoder YUV
(2048 kB)
Sep 13 12:14:39 jupiter ivtv0: Registered device vbi0 for encoder VBI
(1024 kB)
Sep 13 12:14:39 jupiter ivtv0: Registered device video24 for encoder PCM
(320 kB)
Sep 13 12:14:39 jupiter ivtv0: Registered device radio0 for encoder radio
Sep 13 12:14:39 jupiter ivtv0: Initialized card: Hauppauge WinTV PVR-150
Sep 13 12:14:39 jupiter ivtv: End initialization
Sep 13 12:14:42 jupiter ivtv 0000:01:09.0: firmware: requesting
v4l-cx2341x-enc.fw
Sep 13 12:14:43 jupiter ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836
bytes)
Sep 13 12:14:43 jupiter ivtv0: Encoder revision: 0x02060039

Cheers

--
Robin Gilks




_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Tue, 2009-09-15 at 14:27 +1200, Robin Gilks wrote:
> > Andy Walls wrote:
>
> > Given the testing Chris has done with my patches, it looks like using
> > CX23418 A/V core firmware with a CX25843 is returning non-sensical
> > cominations of interrupt status flags in the audio interrupt status
> > register (0x819 IIRC) of the CX25843.
> >
> > In the above the NICAM related flags don't make sense and neither does
> > the AC97 status. The (S)IF L(ost) flag makes no sense with the format
> > detection flags and ormat detetction loop complete flags, etc. Rarely
> > do I get more than 1 flag other than RDS (which is always set for me).
> > When I do get multple flags at once, its FDL and AFC (IIRC).
> >
> > Could you revert the firmware archive to use a known CX2584x specific
> > firmware for the cx25840 firmware file in the archive at
> > dl.ivtvdriver.org?
> >
> > I suspect the CX23418 firmware image being distributed as CX2584x
> > firmware is causing problems for CX2584x chips.
>
> I'm seeing more and more of this bad audio problem with a PAL PVR150 using
> the line input audio and more recent kernel versions (currently Linux
> jupiter 2.6.30-gentoo-r4 #2 SMP Thu Aug 13 23:54:02 NZST 2009 x86_64 AMD
> Athlon(tm) Dual Core Processor 5050e AuthenticAMD GNU/Linux) and newer
> (faster) hardware.
>
> Is there an md5sum that would identify a known good firmware? The files in
> the archive are not very well described (dates don't mean much to me). I'm
> also a bit confused by the device numbers as my dsmeg quotes both cx23416
> and cx25840

I use this (possibly ancient) firmware with my PVR-150MCE:

$ md5sum /lib/firmware/v4l-cx25840.fw
99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw

it works wellfor me, but I barely use analog anymore. IIRC, I pulled
the file from the Windows driver CD for my Hauppauge card. MakoC.rom or
something like that.


The CX23416 is the MPEG encoder, the CX2584[0123] is a broadcast TV
Video and Audio signal decoder and digitizer that feeds digitized video
and audio data to the CX23416 encoder for MPEG encoding.

Regards,
Andy

> This is what I get at startup - very standard Gentoo fare...
>
> Sep 13 12:14:39 jupiter ivtv: Start initialization, version 1.4.1
> Sep 13 12:14:39 jupiter ivtv0: Initializing card 0
> Sep 13 12:14:39 jupiter ivtv0: Autodetected Hauppauge card (cx23416 based)
> Sep 13 12:14:39 jupiter ivtv 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI
> 17 (level, low) -> IRQ 17
> Sep 13 12:14:39 jupiter ivtv0: Unreasonably low latency timer, setting to
> 64 (was 32)
> Sep 13 12:14:39 jupiter ivtv0: Autodetected Hauppauge WinTV PVR-150
> Sep 13 12:14:39 jupiter cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c
> driver #0)
> Sep 13 12:14:39 jupiter tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #0)
> Sep 13 12:14:39 jupiter tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> Sep 13 12:14:39 jupiter wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
> Sep 13 12:14:39 jupiter IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on
> shared IRQs
> Sep 13 12:14:39 jupiter ivtv0: Registered device video0 for encoder MPG
> (4096 kB)
> Sep 13 12:14:39 jupiter ivtv0: Registered device video32 for encoder YUV
> (2048 kB)
> Sep 13 12:14:39 jupiter ivtv0: Registered device vbi0 for encoder VBI
> (1024 kB)
> Sep 13 12:14:39 jupiter ivtv0: Registered device video24 for encoder PCM
> (320 kB)
> Sep 13 12:14:39 jupiter ivtv0: Registered device radio0 for encoder radio
> Sep 13 12:14:39 jupiter ivtv0: Initialized card: Hauppauge WinTV PVR-150
> Sep 13 12:14:39 jupiter ivtv: End initialization
> Sep 13 12:14:42 jupiter ivtv 0000:01:09.0: firmware: requesting
> v4l-cx2341x-enc.fw
> Sep 13 12:14:43 jupiter ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836
> bytes)
> Sep 13 12:14:43 jupiter ivtv0: Encoder revision: 0x02060039

> Cheers
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Tue, Sep 15, 2009 at 10:54:28PM -0400, Andy Walls wrote:
> On Tue, 2009-09-15 at 14:27 +1200, Robin Gilks wrote:
> > > Andy Walls wrote:
> >
> > > Given the testing Chris has done with my patches, it looks like using
> > > CX23418 A/V core firmware with a CX25843 is returning non-sensical
> > > cominations of interrupt status flags in the audio interrupt status
> > > register (0x819 IIRC) of the CX25843.
> > >
> > > In the above the NICAM related flags don't make sense and neither does
> > > the AC97 status. The (S)IF L(ost) flag makes no sense with the format
> > > detection flags and ormat detetction loop complete flags, etc. Rarely
> > > do I get more than 1 flag other than RDS (which is always set for me).
> > > When I do get multple flags at once, its FDL and AFC (IIRC).
> > >
> > > Could you revert the firmware archive to use a known CX2584x specific
> > > firmware for the cx25840 firmware file in the archive at
> > > dl.ivtvdriver.org?
> > >
> > > I suspect the CX23418 firmware image being distributed as CX2584x
> > > firmware is causing problems for CX2584x chips.
> >
> > I'm seeing more and more of this bad audio problem with a PAL PVR150 using
> > the line input audio and more recent kernel versions (currently Linux
> > jupiter 2.6.30-gentoo-r4 #2 SMP Thu Aug 13 23:54:02 NZST 2009 x86_64 AMD
> > Athlon(tm) Dual Core Processor 5050e AuthenticAMD GNU/Linux) and newer
> > (faster) hardware.
> >
> > Is there an md5sum that would identify a known good firmware? The files in
> > the archive are not very well described (dates don't mean much to me). I'm
> > also a bit confused by the device numbers as my dsmeg quotes both cx23416
> > and cx25840
>
> I use this (possibly ancient) firmware with my PVR-150MCE:
>
> $ md5sum /lib/firmware/v4l-cx25840.fw
> 99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw
>
> it works wellfor me, but I barely use analog anymore. IIRC, I pulled
> the file from the Windows driver CD for my Hauppauge card. MakoC.rom or
> something like that.
>
>
> The CX23416 is the MPEG encoder, the CX2584[0123] is a broadcast TV
> Video and Audio signal decoder and digitizer that feeds digitized video
> and audio data to the CX23416 encoder for MPEG encoding.
>
> Regards,
> Andy

Looking at md5sums of the firmware files at dl.ivtvdriver.org/ivtv/firmware,
I see that Andy is using the pre-20080701 version of v4l-cx25840.fw:

588f081b562f5c653a3db1ad8f65939a cx18-firmware/v4l-cx23418-apu.fw
b6c7ed64bc44b1a6e0840adaeac39d79 cx18-firmware/v4l-cx23418-cpu.fw
b3704908fd058485f3ef136941b2e513 cx18-firmware/v4l-cx23418-dig.fw
305dba74bbe5905447add8883f3ecb68 ivtv-firmware-20060701/v4l-cx2341x-dec.fw
d85cb08382395390dc95ac6ebc2205f9 ivtv-firmware-20060701/v4l-cx2341x-enc.fw
99836e41ccb28c7b373e87686f93712a ivtv-firmware-20060701/v4l-cx25840.fw
305dba74bbe5905447add8883f3ecb68 ivtv-firmware-20061007/v4l-cx2341x-dec.fw
d85cb08382395390dc95ac6ebc2205f9 ivtv-firmware-20061007/v4l-cx2341x-enc.fw
99836e41ccb28c7b373e87686f93712a ivtv-firmware-20061007/v4l-cx25840.fw
305dba74bbe5905447add8883f3ecb68 ivtv-firmware-20070217/v4l-cx2341x-dec.fw
9b39b3d3bba1ce2da40f82ef0c50ef48 ivtv-firmware-20070217/v4l-cx2341x-enc.fw
99836e41ccb28c7b373e87686f93712a ivtv-firmware-20070217/v4l-cx25840.fw
305dba74bbe5905447add8883f3ecb68 ivtv-firmware-20080701/v4l-cx2341x-dec.fw
9b39b3d3bba1ce2da40f82ef0c50ef48 ivtv-firmware-20080701/v4l-cx2341x-enc.fw
b3704908fd058485f3ef136941b2e513 ivtv-firmware-20080701/v4l-cx25840.fw
3a4803384f749d644ee1f1ca9dcb12fa HcwMakoB.ROM

My system has files matching ivtv-firmware-20080701 and the intermittent
"tinny" audio issue on my PVR-150 (I use line-in). This install is from
Nov 2008, and my previous install (~Feb 2007) on the same system did not
have the audio issue. I will try reverting to
ivtv-firmware-20070217/v4l-cx25840.fw and see if my audio issue goes away.

Noah


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Wed, Sep 16, 2009 at 12:27 PM, Noah Beck <noah.b.beck@gmail.com> wrote:
> On Tue, Sep 15, 2009 at 10:54:28PM -0400, Andy Walls wrote:
>> On Tue, 2009-09-15 at 14:27 +1200, Robin Gilks wrote:
>> > > Andy Walls wrote:
>> >
>> > > Given the testing Chris has done with my patches, it looks like using
>> > > CX23418 A/V core firmware with a CX25843 is returning non-sensical
>> > > cominations of interrupt status flags in the audio interrupt status
>> > > register (0x819 IIRC) of the CX25843.
>> > >
>> > > In the above the NICAM related flags don't make sense and neither does
>> > > the AC97 status.  The (S)IF L(ost) flag makes no sense with the format
>> > > detection flags and ormat detetction loop complete flags, etc.   Rarely
>> > > do I get more than 1 flag other than RDS (which is always set for me).
>> > > When I do get multple flags at once, its FDL and AFC (IIRC).
>> > >
>> > > Could you revert the firmware archive to use a known CX2584x specific
>> > > firmware for the cx25840 firmware file in the archive at
>> > > dl.ivtvdriver.org?
>> > >
>> > > I suspect the CX23418 firmware image being distributed as CX2584x
>> > > firmware is causing problems for CX2584x chips.
>> >
>> > I'm seeing more and more of this bad audio problem with a PAL PVR150 using
>> > the line input audio and more recent kernel versions (currently Linux
>> > jupiter 2.6.30-gentoo-r4 #2 SMP Thu Aug 13 23:54:02 NZST 2009 x86_64 AMD
>> > Athlon(tm) Dual Core Processor 5050e AuthenticAMD GNU/Linux) and newer
>> > (faster) hardware.
>> >
>> > Is there an md5sum that would identify a known good firmware? The files in
>> > the archive are not very well described (dates don't mean much to me). I'm
>> > also a bit confused by the device numbers as my dsmeg quotes both cx23416
>> > and cx25840
>>
>> I use this (possibly ancient) firmware with my PVR-150MCE:
>>
>> $ md5sum /lib/firmware/v4l-cx25840.fw
>> 99836e41ccb28c7b373e87686f93712a  /lib/firmware/v4l-cx25840.fw
>>
>> it works wellfor me, but I barely use analog anymore.  IIRC, I pulled
>> the file from the Windows driver CD for my Hauppauge card.  MakoC.rom or
>> something like that.
>>
>>
>> The CX23416 is the MPEG encoder, the CX2584[0123] is a broadcast TV
>> Video and Audio signal decoder and digitizer that feeds digitized video
>> and audio data to the CX23416 encoder for MPEG encoding.
>>
>> Regards,
>> Andy
>
> Looking at md5sums of the firmware files at dl.ivtvdriver.org/ivtv/firmware,
> I see that Andy is using the pre-20080701 version of v4l-cx25840.fw:
>
> 588f081b562f5c653a3db1ad8f65939a  cx18-firmware/v4l-cx23418-apu.fw
> b6c7ed64bc44b1a6e0840adaeac39d79  cx18-firmware/v4l-cx23418-cpu.fw
> b3704908fd058485f3ef136941b2e513  cx18-firmware/v4l-cx23418-dig.fw
> 305dba74bbe5905447add8883f3ecb68  ivtv-firmware-20060701/v4l-cx2341x-dec.fw
> d85cb08382395390dc95ac6ebc2205f9  ivtv-firmware-20060701/v4l-cx2341x-enc.fw
> 99836e41ccb28c7b373e87686f93712a  ivtv-firmware-20060701/v4l-cx25840.fw
> 305dba74bbe5905447add8883f3ecb68  ivtv-firmware-20061007/v4l-cx2341x-dec.fw
> d85cb08382395390dc95ac6ebc2205f9  ivtv-firmware-20061007/v4l-cx2341x-enc.fw
> 99836e41ccb28c7b373e87686f93712a  ivtv-firmware-20061007/v4l-cx25840.fw
> 305dba74bbe5905447add8883f3ecb68  ivtv-firmware-20070217/v4l-cx2341x-dec.fw
> 9b39b3d3bba1ce2da40f82ef0c50ef48  ivtv-firmware-20070217/v4l-cx2341x-enc.fw
> 99836e41ccb28c7b373e87686f93712a  ivtv-firmware-20070217/v4l-cx25840.fw
> 305dba74bbe5905447add8883f3ecb68  ivtv-firmware-20080701/v4l-cx2341x-dec.fw
> 9b39b3d3bba1ce2da40f82ef0c50ef48  ivtv-firmware-20080701/v4l-cx2341x-enc.fw
> b3704908fd058485f3ef136941b2e513  ivtv-firmware-20080701/v4l-cx25840.fw
> 3a4803384f749d644ee1f1ca9dcb12fa  HcwMakoB.ROM
>
> My system has files matching ivtv-firmware-20080701 and the intermittent
> "tinny" audio issue on my PVR-150 (I use line-in).  This install is from
> Nov 2008, and my previous install (~Feb 2007) on the same system did not
> have the audio issue.  I will try reverting to
> ivtv-firmware-20070217/v4l-cx25840.fw and see if my audio issue goes away.

Changing the firmware version on my myth box did not appear to affect
the "tinny" audio issue.

Noah

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel