Mailing List Archive

On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> On 03/02/10 07:40, Andy Walls wrote:
> > Again, maybe dynamically allocating these work order objects from the
> > kernel as needed, would be better from a small dynamically allocated
> > pool for each card. I was concerned that the interrupt handler was
> > taking to long at the time I implemented the things the way they are
> > now.
> ..
>
> I haven't seen that particular issue again, with or without increasing
> the work orders, so hopefully it won't recur.

OK.


> But after updating to the tip of the v4l2-dvb git tree last week,
> I've been hitting the "no audio" on analog recordings bug much more often.

Is that tuner audio or baseband (line-in) audio?



> Digging through google, it appears this problem has been around as long
> as the cx18 driver has existed, with no clear resolution. Lots of people
> have reported it to you before, and nobody has found a silver bullet fix.

Correct. I thought it was completely gone, but apparently, there just
isn't a lot of reporting of this intermittent problem.


> The problem is still there.
>
> I have now spent a good many hours trying to isolate *when* it happens,
> and have narrowed it down to module initialization.
>
> Basically, if the audio is working after modprobe cx18, it then continues
> to work from recording to recording until the next reboot.
>
> If the audio is not working after modprobe, then simply doing rmmod/modprobe
> in a loop (until working audio is achieved) is enough to cure it.

Good to know.


> So for my Mythtv box here, I now have a script to check for missing audio
> and do the rmmod/modprobe. This is a good, effective workaround.
>
> http://rtr.ca/hvr1600/fix_hvr1600_audio.sh
>
> That's a link to my script.
>
> As for the actual underlying cause/bug, it's still not clear what is happening.
> But the problem is a LOT more prevalent (for me, and for two other people I know)
> with versions of the cx18 driver since spring 2009.
>
> My suspicion is that the firmware download for the APU is somehow being corrupted,
> and now that the driver downloads the firmware *twice* during init, it doubles the
> odds of said corruption. Just a theory, but it's the best fit so far.

Please isolate an APU load and initialization problem, by seeing if
audio fails for both tuner audio and baseband audio.


Here are all the potential problem areas I can think of:

1. A/V digitizer/decoder audio detection firmware load and init. (I've
added firmware readback verification to try and head this off.)

2. A/V digitizer decoder audio microcontroller hard reset and "soft"
reset sequencing. (I think the cx18 driver has this wrong ATM.)

3. APU load and init. (The double load is to fix a DTV TS stream bug on
every other APU & CPU firmware load sequence. The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)

4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs. (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)

5. A/V decoder audio clock PLL stops operating due to being programmed
out of range. (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)

6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
to a problen Helen Buus reported with cable TV.)



I think #2 is the real problem. I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.

I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:

http://linuxtv.org/hg/~awalls/cx18-audio

If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.


> I think we have some nasty i2c issues somewhere in the kernel.

The only I2C connected devices for analog audio are the analog tuner IF
demodulator chip for SIF audio and the CS5345 chip for baseband audio.
Unlike the PVR-150, which has an I2C connected CX25843 A/V decoder, the
CX23418's A/V decoder is integrated and accessed via PCI bus registers.

With that said, the CX23418 will sometimes have to let register access
over the PCI bus fail. For that, I have routines in cx18-io.[ch] to
perform retries. You may wish to add a log statement there to watch for
retry loops that completely fail.


Thanks for the troubleshooting and reporting.

Regards,
Andy



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

On Tue, 2010-03-16 at 00:49 -0400, Mark Lord wrote:
> On 03/15/10 07:51, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:

> >> If the audio is not working after modprobe, then simply doing rmmod/modprobe
> >> in a loop (until working audio is achieved) is enough to cure it.
> ..
>
> Well, crap. Tonight our MythTV box proved that assertion to be false.
> The cx18 audio was okay after modprobe, but went bad a few seconds later,
> when mythbackend started up and did the initial channel tuning.
> I have a script that attempts audio input toggling when that happens,
> but it had no effect.

I'll note from your logs that you're capturing using the 48 ksps audio
sampling rate with tuner audio.

I've never had a problem with the AUX_PLL with 48 ksps audio, so I'm
going to assume the AUX_PLL isn't the problem's cause.




> rmmod/modprobe is still the only "solution",
> and it's rather difficult to do those while mythbackend is running.

> >
> > I've got a first WAG at fixing the resets of the audio microcontroller's
> > resets at:
> >
> > http://linuxtv.org/hg/~awalls/cx18-audio
> >
> > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > from 0x810 to 0x9cc, although that may not work either.
> ..
>
> I'll have a go at that, and anything else you can dream up as well.

Here's an easy one:


I see from the log your work-around is failing:

Mar 13 14:30:04 duke logger: /dev/video1: fix_hvr1600_stutter.sh: Pre-initializing
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: HVR1600/cx18 audio bug, reloading cx18 driver
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: rmmod cx18 failed

If a cx18 video device node is open or a cx18-alsa device node is open
you won't be able to unload the cx18 and cx18-alsa modules.

Move the cx18-alsa.ko module out of the way so the kernel can't find it
and load it. Then you never have to worry about something like
pulseaduio keeping it held open.



I see in your log that this is a tuner audio standard autodetection
problem in the A/V digitizer/decoder:

Mar 13 14:42:16 duke kernel: cx18-0 843: Video signal: present
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected format: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified standard: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified video input: Composite 7
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio mode: mono
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio standard: no detected audio standard
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio muted: yes
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio microcontroller: running
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio standard: automatic detection
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio system: BTSC
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audio input: Tuner (In8)
Mar 13 14:42:16 duke kernel: cx18-0 843: Preferred audio mode: stereo

The built-in A/V digitzer/decoder's microcontroller won't unmute the
audio until it has detected the standard and set the registers.

I also note the "channel change" (audio input toggling from tuner to
composite in and back?) is having no effect:

Mar 13 14:30:23 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround
Mar 13 14:30:24 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed

Which means the audio microcontroller didn't restart it's detection loop
or the detection loop is still failing to find anything. It should
restart on an input toggle.


This means your problem is occuring in the A/V digitizer or before it;
ruling out the APU or the APU firmware, given the current information.


So the areas to concentrate on here are:


a. digitizer audio standard detection microcontroller intitialization,
reset, and restart of the format detection loop

b. TDA9887 analog IF demodulator programming via the CX23418's I2C
master

c. digitizer audio standard detection microcontroller firmware load and
verification (the cx18 driver already does a lot here, but it may be
worth re-inspecting the code)

d. digitizer analog front end and AUX PLL settings for SIF audio (these
should be correct though, so it is unlikely to be the problem)


> But not for a few days -- really really crazy busy at work right now.

Same here. Crazy at work and home. I don't mind waiting.


> I am a Linux kernel developer, so I can handle patches and stuff
> if you have any to offer.

I'll keep that in mind.



> Oh.. attached is a full log from a failure a few nights ago.
> This one has the full card status dump included, which shows
> where the audio is being muted at.
>
> ...
> > With that said, the CX23418 will sometimes have to let register access
> > over the PCI bus fail. For that, I have routines in cx18-io.[ch] to
> > perform retries. You may wish to add a log statement there to watch for
> > retry loops that completely fail.
> ..
>
> I did that a while ago, and they didn't trigger back then.

OK.

Regards,
Andy



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

On 15/03/10 07:51 AM, Andy Walls wrote:
> On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
>> On 03/02/10 07:40, Andy Walls wrote:
..
>> after updating to the tip of the v4l2-dvb git tree last week,
>> I've been hitting the "no audio" on analog recordings bug much more often.
>>
>> Digging through google, it appears this problem has been around as long
>> as the cx18 driver has existed, with no clear resolution. Lots of people
>> have reported it to you before, and nobody has found a silver bullet fix.
..
> Here are all the potential problem areas I can think of:
>
> 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> added firmware readback verification to try and head this off.)
>
> 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> reset sequencing. (I think the cx18 driver has this wrong ATM.)
>
> 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> fix the audio bitrate problem on first capture after a double firmware
> load.)
>
> 4. AI1 Mux setting failing when switching between the internal A/V
> decoder's I2S output and the external I2S inputs. (I thought I had this
> fixed, but I don't have detailed register specs for that register - so
> maybe not.)
>
> 5. A/V decoder audio clock PLL stops operating due to being programmed
> out of range. (This was a problem for 32 ksps audio a while ago, but
> I'm pretty confident I have it fixed.)
>
> 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> to a problen Helen Buus reported with cable TV.)
>
> I think #2 is the real problem. I just started to disassmble the
> digitizer firmware 2 nights ago to see if I could get some insight as to
> how to properly reset it.
>
> I've got a first WAG at fixing the resets of the audio microcontroller's
> resets at:
>
> http://linuxtv.org/hg/~awalls/cx18-audio
>
> If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> from 0x810 to 0x9cc, although that may not work either.
..
> Thanks for the troubleshooting and reporting.
..

Back at this again today, after a month away from it -- getting tired
of watching "Survivor" with closed-captioning instead of audio. :)

I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb. Patch attached for reference.

So far, so good. I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> On 15/03/10 07:51 AM, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> On 03/02/10 07:40, Andy Walls wrote:
> ..
> >> after updating to the tip of the v4l2-dvb git tree last week,
> >> I've been hitting the "no audio" on analog recordings bug much more often.
> >>
> >> Digging through google, it appears this problem has been around as long
> >> as the cx18 driver has existed, with no clear resolution. Lots of people
> >> have reported it to you before, and nobody has found a silver bullet fix.
> ..
> > Here are all the potential problem areas I can think of:
> >
> > 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> > added firmware readback verification to try and head this off.)
> >
> > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > reset sequencing. (I think the cx18 driver has this wrong ATM.)
> >
> > 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> > every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> > fix the audio bitrate problem on first capture after a double firmware
> > load.)
> >
> > 4. AI1 Mux setting failing when switching between the internal A/V
> > decoder's I2S output and the external I2S inputs. (I thought I had this
> > fixed, but I don't have detailed register specs for that register - so
> > maybe not.)
> >
> > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > out of range. (This was a problem for 32 ksps audio a while ago, but
> > I'm pretty confident I have it fixed.)
> >
> > 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> > to a problen Helen Buus reported with cable TV.)
> >
> > I think #2 is the real problem. I just started to disassmble the
> > digitizer firmware 2 nights ago to see if I could get some insight as to
> > how to properly reset it.
> >
> > I've got a first WAG at fixing the resets of the audio microcontroller's
> > resets at:
> >
> > http://linuxtv.org/hg/~awalls/cx18-audio
> >
> > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > from 0x810 to 0x9cc, although that may not work either.
> ..
> > Thanks for the troubleshooting and reporting.
> ..
>
> Back at this again today, after a month away from it -- getting tired
> of watching "Survivor" with closed-captioning instead of audio. :)
>
> I pulled your (Andy) repository today, and merged the cx18 audio reset
> changes from it into today's tip from v4l-dvb. Patch attached for reference.
>
> So far, so good. I'll keep tabs on it over time, and see if the audio
> is stable, or if it still fails once in a while.

Hmmm. Darren's having problems (loss of video/black screen) with my
patches under my cx18-audio repo, but I'm not quite convinced he doesn't
have some other PCI bus problem either.

Anyway, my plan now is this:

1. on cx18-av-core.c:input_change()
a. set register 0x808 for audio autodetection
b. restart the format detection loop
c. set or reset a 1.5 second timeout

2. after the timer expires, if no audio standard was detected,
a. force the audio standard by programming register 0x808
(e.g. BTSC for NTSC-M)
b. restart the format detection loop so the micrcontroller will
do the unmute when it detects audio



Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?

Regards,
Andy


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

On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> > On 15/03/10 07:51 AM, Andy Walls wrote:
> > > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> > >> On 03/02/10 07:40, Andy Walls wrote:
> > ..
> > >> after updating to the tip of the v4l2-dvb git tree last week,
> > >> I've been hitting the "no audio" on analog recordings bug much more often.
> > >>
> > >> Digging through google, it appears this problem has been around as long
> > >> as the cx18 driver has existed, with no clear resolution. Lots of people
> > >> have reported it to you before, and nobody has found a silver bullet fix.
> > ..
> > > Here are all the potential problem areas I can think of:
> > >
> > > 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> > > added firmware readback verification to try and head this off.)
> > >
> > > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > > reset sequencing. (I think the cx18 driver has this wrong ATM.)
> > >
> > > 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> > > every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> > > fix the audio bitrate problem on first capture after a double firmware
> > > load.)
> > >
> > > 4. AI1 Mux setting failing when switching between the internal A/V
> > > decoder's I2S output and the external I2S inputs. (I thought I had this
> > > fixed, but I don't have detailed register specs for that register - so
> > > maybe not.)
> > >
> > > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > > out of range. (This was a problem for 32 ksps audio a while ago, but
> > > I'm pretty confident I have it fixed.)
> > >
> > > 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> > > to a problen Helen Buus reported with cable TV.)
> > >
> > > I think #2 is the real problem. I just started to disassmble the
> > > digitizer firmware 2 nights ago to see if I could get some insight as to
> > > how to properly reset it.
> > >
> > > I've got a first WAG at fixing the resets of the audio microcontroller's
> > > resets at:
> > >
> > > http://linuxtv.org/hg/~awalls/cx18-audio
> > >
> > > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > > from 0x810 to 0x9cc, although that may not work either.
> > ..
> > > Thanks for the troubleshooting and reporting.
> > ..
> >
> > Back at this again today, after a month away from it -- getting tired
> > of watching "Survivor" with closed-captioning instead of audio. :)
> >
> > I pulled your (Andy) repository today, and merged the cx18 audio reset
> > changes from it into today's tip from v4l-dvb. Patch attached for reference.
> >
> > So far, so good. I'll keep tabs on it over time, and see if the audio
> > is stable, or if it still fails once in a while.
>
> Hmmm. Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
>
> Anyway, my plan now is this:
>
> 1. on cx18-av-core.c:input_change()
> a. set register 0x808 for audio autodetection
> b. restart the format detection loop
> c. set or reset a 1.5 second timeout
>
> 2. after the timer expires, if no audio standard was detected,
> a. force the audio standard by programming register 0x808
> (e.g. BTSC for NTSC-M)
> b. restart the format detection loop so the micrcontroller will
> do the unmute when it detects audio
>
>
>
> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?

Hey, I just found an OTA analog broadcast on channel 23! I even can
reproduce the problem of the audio microcontroller not detecting the
audio standard (shoot it just kicked in and figured it out).

Anyway this will help me turn around something.

Regards,
Andy



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

On 10/04/10 06:54 PM, Andy Walls wrote:
>
> Hmmm. Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
>
> Anyway, my plan now is this:
>
> 1. on cx18-av-core.c:input_change()
> a. set register 0x808 for audio autodetection
> b. restart the format detection loop
> c. set or reset a 1.5 second timeout
>
> 2. after the timer expires, if no audio standard was detected,
> a. force the audio standard by programming register 0x808
> (e.g. BTSC for NTSC-M)
> b. restart the format detection loop so the micrcontroller will
> do the unmute when it detects audio
>
> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
..

I'm in Canada, using the tuner for over-the-air NTSC broadcasts.

Cheers!
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> On 10/04/10 06:54 PM, Andy Walls wrote:
> >
> > Hmmm. Darren's having problems (loss of video/black screen) with my
> > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > have some other PCI bus problem either.
> >
> > Anyway, my plan now is this:
> >
> > 1. on cx18-av-core.c:input_change()
> > a. set register 0x808 for audio autodetection
> > b. restart the format detection loop
> > c. set or reset a 1.5 second timeout
> >
> > 2. after the timer expires, if no audio standard was detected,
> > a. force the audio standard by programming register 0x808
> > (e.g. BTSC for NTSC-M)
> > b. restart the format detection loop so the micrcontroller will
> > do the unmute when it detects audio
> >
> > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> ..
>
> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.


Try this:

http://linuxtv.org/hg/~awalls/cx18-audio2

this waits 1.5 seconds after an input/channel change to see if the audio
standard micrcontroller can detect the standard. If it can't, the
driver tells it to try a fallback detection. Right now, only the NTSC-M
fallback detection is set to force a mode (i.e. BTSC), all the others
"fall back" to their same auto-detection.

Some annoyances with the fallback to a forced audio standard, mode, and
format:

1. Static gets unmuted on stations with no signal. :(

2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
+R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
the fallback setting magic number (0x1101) in
cx18-av-core.c:input_change().


Regards,
Andy


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

On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > a. set register 0x808 for audio autodetection
> > > b. restart the format detection loop
> > > c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > a. force the audio standard by programming register 0x808
> > > (e.g. BTSC for NTSC-M)
> > > b. restart the format detection loop so the micrcontroller will
> > > do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> > ..
> >
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
^^^

Bah, wrong byte. That should have been the LSN of the MSB of the 0x1101
number. I'm too tired.

Regards,
Andy

> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
>
>
> 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 Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > a. set register 0x808 for audio autodetection
> > > b. restart the format detection loop
> > > c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > a. force the audio standard by programming register 0x808
> > > (e.g. BTSC for NTSC-M)
> > > b. restart the format detection loop so the micrcontroller will
> > > do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> > ..
> >
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().

I fixed #2. I had a bug so the first patch didn't properly set the
fallback audio mode.

I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
into consideration that we might be using a forced audio mode vs. auto
detection. However, that is not essential for testing; this should be
good enough for testing.

Regards,
Andy



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

On 11/04/10 07:47 AM, Andy Walls wrote:
> On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
>> Try this:
>>
>> http://linuxtv.org/hg/~awalls/cx18-audio2
>>
>> this waits 1.5 seconds after an input/channel change to see if the audio
>> standard micrcontroller can detect the standard. If it can't, the
>> driver tells it to try a fallback detection. Right now, only the NTSC-M
>> fallback detection is set to force a mode (i.e. BTSC), all the others
>> "fall back" to their same auto-detection.
>>
>> Some annoyances with the fallback to a forced audio standard, mode, and
>> format:
>>
>> 1. Static gets unmuted on stations with no signal. :(
>>
>> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
>> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
>> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
>> the fallback setting magic number (0x1101) in
>> cx18-av-core.c:input_change().
>
> I fixed #2. I had a bug so the first patch didn't properly set the
> fallback audio mode.
>
> I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> into consideration that we might be using a forced audio mode vs. auto
> detection. However, that is not essential for testing; this should be
> good enough for testing.
..

Those new patches don't want to coexist with the earlier hard/soft reset
changes. There's always a chance that *both* things might be needed,
and the reset stuff didn't look obviously "bad". Why dropped?

Thanks
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote:
> On 11/04/10 07:47 AM, Andy Walls wrote:
> > On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> >> Try this:
> >>
> >> http://linuxtv.org/hg/~awalls/cx18-audio2
> >>
> >> this waits 1.5 seconds after an input/channel change to see if the audio
> >> standard micrcontroller can detect the standard. If it can't, the
> >> driver tells it to try a fallback detection. Right now, only the NTSC-M
> >> fallback detection is set to force a mode (i.e. BTSC), all the others
> >> "fall back" to their same auto-detection.
> >>
> >> Some annoyances with the fallback to a forced audio standard, mode, and
> >> format:
> >>
> >> 1. Static gets unmuted on stations with no signal. :(
> >>
> >> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> >> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> >> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> >> the fallback setting magic number (0x1101) in
> >> cx18-av-core.c:input_change().
> >
> > I fixed #2. I had a bug so the first patch didn't properly set the
> > fallback audio mode.
> >
> > I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> > into consideration that we might be using a forced audio mode vs. auto
> > detection. However, that is not essential for testing; this should be
> > good enough for testing.
> ..
>
> Those new patches don't want to coexist with the earlier hard/soft reset
> changes. There's always a chance that *both* things might be needed,
> and the reset stuff didn't look obviously "bad". Why dropped?

Because...

1. Darren had problems with a black video screen with them and so did I
(once I found an analog OTA station).

2. I also suspect those previous patches were not performing the format
detection loop reset properly.

3. One could possibly reset the microcontroller all day long without
auto-detection ever working. Also autodetection will auto-mute, and
restart the detection loop, if it thinks the audio carrier went away.

4. Falling back to a known used audio standard, format, and mode is
guaranteed to work. I guess it can be a problem in some region for some
video stanadrd where one just can't know what each broadcaster is using.
For NTSC-M this is not the case: BTSC at 4.5 MHz is always used.

5. I don't understand the exact failure mode of why the microcontroller
is failing to detect the audio standard, so any other fix that doesn't
explicitly set a standard will likely be unreliable. I'm tired of audio
detection fixes with unpredictable outcomes based on variations in cable
and OTA signal sources. Forcing the microcontroller to a particular
standard, after autodetection fails, gives a deterministic outcome.

(BTW, we really do need the microcontroller to do some work for us. No
documentation accessable to me has enough detail to allow one to fully
program the audio decoder portion of the A/V core. We have to rely on
the microntroller firmware to set up some of the undocumented or
unexplained registers.)


I can always throw the other reset patches back in I guess, but this
latest patch set should dominate the behavior of the microcontroller (if
I didn't miss something because I was tired).

I would be interested in hearing how frequent these patches show "forced
audio standard" for you:

[ 389.388200] cx18-0 843: Detected format: NTSC-M
[ 389.388204] cx18-0 843: Specified standard: NTSC-M
[ 389.388208] cx18-0 843: Specified video input: Composite 7
[ 389.388212] cx18-0 843: Specified audioclock freq: 48000 Hz
[ 389.388232] cx18-0 843: Detected audio mode: forced mode
[ 389.388237] cx18-0 843: Detected audio standard: forced audio standard
[ 389.388241] cx18-0 843: Audio muted: no
[ 389.388245] cx18-0 843: Audio microcontroller: running
[ 389.388249] cx18-0 843: Configured audio standard: BTSC
[ 389.388253] cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B)
[ 389.388257] cx18-0 843: Specified audio input: Tuner (In8)
[ 389.388261] cx18-0 843: Preferred audio mode: stereo

meaning that the fallback audio settings were used because auto
detection failed.

Regards,
Andy


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

Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
>
>> On 10/04/10 06:54 PM, Andy Walls wrote:
>>
>>> Hmmm. Darren's having problems (loss of video/black screen) with my
>>> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
>>> have some other PCI bus problem either.
>>>
>>> Anyway, my plan now is this:
>>>
>>> 1. on cx18-av-core.c:input_change()
>>> a. set register 0x808 for audio autodetection
>>> b. restart the format detection loop
>>> c. set or reset a 1.5 second timeout
>>>
>>> 2. after the timer expires, if no audio standard was detected,
>>> a. force the audio standard by programming register 0x808
>>> (e.g. BTSC for NTSC-M)
>>> b. restart the format detection loop so the micrcontroller will
>>> do the unmute when it detects audio
>>>
>>> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
>>>
>> ..
>>
>> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>>
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
>
>
> Regards,
> Andy
>
>
So far, it seems fine, no black screens, and audio seems to be fine.

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

On 11/04/10 03:01 PM, Andy Walls wrote:
..
> I can always throw the other reset patches back in I guess, but this
> latest patch set should dominate the behavior of the microcontroller (if
> I didn't miss something because I was tired).
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..

Thanks. Will do.

I've added a printk() to the fallback path, so that it will show up in
the syslog whenever the fallback is used.

So far, no problem. But prior to now, the HVR-1600 regularly failed about
once every 2-3 days according to the script I have which tests for the issue.

On a similar note, while checking the logs last evening, I discovered that
the muted episode of "Survivor Heros & Villians" (two weeks ago) was actually
recorded on the _PVR-250_ card. With no audio. This has happened before,
though rarely -- perhaps once every 3-6 months or so.

I wonder if a similar fix/workaround could be appropriate for that card as well?
In the mean while, I guess I'll update my scripts to test/report for that
one as well as the cx18/hvr1600.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On 11/04/10 03:01 PM, Andy Walls wrote:
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..

The MythTV box here has many tuners, most of which are not used every power-up.
But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
each time the system boots up to record/play something.

So.. in the logs from the other night, there are some "fallback" messages.
But since the HVR1600 was not actually used to record anything,
I don't know for sure if the audio fallback actually "worked",
other than that v4l-ctl reported non-muted audio afterwards.

The abridged syslog is below.
Something I find interesting, is that it reported having to
fallback twice on this boot (once during the initial anti-stutter tune,
and again when mythbackend started up).

I wonder if this means that once the audio bug is present,
it remains present until the next time the driver is loaded/unloaded.

Which matches previous observations.
The fallback (hopefully) works around this, but there's still a bug
somewhere that is preventing the audio from working without the fallback.

Cheers

Mark Lord

* * * *

Apr 12 03:56:55 duke kernel: cx18: Start initialization, version 1.4.0
Apr 12 03:56:55 duke kernel: cx18-0: Initializing card 0
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge card
Apr 12 03:56:55 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Apr 12 03:56:55 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
Apr 12 03:56:55 duke kernel: cx18-0: cx23418 revision 01010000 (B)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: has radio
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
Apr 12 03:56:55 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Apr 12 03:56:55 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: tda9887 2-0043: creating new instance
Apr 12 03:56:55 duke kernel: tda9887 2-0043: tda988[5/6/7] found
Apr 12 03:56:55 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: creating new instance
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
Apr 12 03:56:55 duke kernel: DVB: registering new adapter (cx18)
Apr 12 03:56:55 duke kernel: MXL5005S: Attached at address 0x63
Apr 12 03:56:55 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Apr 12 03:56:55 duke kernel: cx18-0: DVB Frontend registered
Apr 12 03:56:55 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device radio1 for encoder radio
Apr 12 03:56:55 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18: End initialization

Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
Apr 12 03:56:58 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
Apr 12 03:56:59 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
Apr 12 03:56:59 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)

Apr 12 03:57:00 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
Apr 12 03:57:00 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Apr 12 03:57:00 duke kernel: ivtv0: Encoder revision: 0x02060039

Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
Apr 12 03:57:01 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection <-------------------
Apr 12 03:57:01 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
Apr 12 03:57:01 duke kernel: irrcv0: i2c IR (Hauppauge) as /class/irrcv/irrcv0
Apr 12 03:57:01 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)

Apr 12 03:57:02 duke logger[4238]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
Apr 12 03:57:02 duke logger: /dev/video1: fix_hvr1600_audio.sh: Pre-initializing

Apr 12 03:57:04 duke logger: /dev/video1: fix_hvr1600_audio.sh: HVR1600/cx18 audio ok.
Apr 12 03:57:04 duke nanny.mythbackend[4263]: mythbackend[4265] started

Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: Selecting '2C' (hvr1600)
Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: writing 0x08 [- - - - 1 - - -]

Apr 12 03:57:22 duke logger: channel_change: /dev/video1: cx18/hvr1600 audio ok.
Apr 12 03:57:22 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection <-------------------
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: Selecting '1D' (pvr250)
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: writing 0x0b [- - - - 1 - 1 1]
Apr 12 03:57:23 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.

Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: Selecting '1C' (pvr250)
Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: writing 0x0a [- - - - 1 - 1 -]
Apr 12 03:59:32 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.

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

On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
> On 11/04/10 03:01 PM, Andy Walls wrote:
> >
> > I would be interested in hearing how frequent these patches show "forced
> > audio standard" for you:
> ..
>
> The MythTV box here has many tuners, most of which are not used every power-up.
> But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
> each time the system boots up to record/play something.
>
> So.. in the logs from the other night, there are some "fallback" messages.
> But since the HVR1600 was not actually used to record anything,
> I don't know for sure if the audio fallback actually "worked",
> other than that v4l-ctl reported non-muted audio afterwards.

Forcing BTSC for NTSC-M will always work. You should hear something.


> The abridged syslog is below.
> Something I find interesting, is that it reported having to
> fallback twice on this boot (once during the initial anti-stutter tune,

BTW you shouldn't need to do that anymore. The audio "stutter" was a
CX23418 APU and CPU firmware state problem about audio sampling rate
that the newer versions of the driver handle by loading those firmwares
twice and calling the APU firmware's APU_RESET_AI call. The first
analog capture should never "stutter" anymore.

> and again when mythbackend started up).

Whenever cx18_av_core.c:input_change() is called, the audio
microcontroller audio standard autodetection is restarted. This
function gets called at least once for each of these ioctl()s:

VIDIOC_S_STD
VIDIOC_S_FREQUENCY
VIDIOC_S_INPUT

and probably for some other ioctl()s as well. VIDIOC_S_FREQUENCY is
called for every channel tuning operation. Your logs are probably
showing the effects of calls to S_INPUT and S_FREQUENCY. You can

modprobe cx18 debug=0x10

to log cx18 ioctl calls if you are interested.


> I wonder if this means that once the audio bug is present,
> it remains present until the next time the driver is loaded/unloaded.

If we're talking about audio standard auto detection not working, I'll
guess "no". Too much really depends on the input signal quality.

Auto detection working requires the analog tuner assembly to output a
stable SIF signal (from the broadcaster) upon which the CX23418 A/V
decoder will operate.

The TV channels needs to have an audio signal. If you tune to a channel
with no signal, audio autodetection will always fail and fallback to the
forced mode. The cx18 driver defaults to channel 4 on startup.



> Which matches previous observations.
> The fallback (hopefully) works around this, but there's still a bug
> somewhere that is preventing the audio from working without the fallback.

A way to test your hypothesis is to run a script that repeatedly tunes
among known analog stations, perhaps with ivtv-tune, and then check the
results of audio detection, perhaps with v4l2-ctl, after a few seconds.
You could also save a short segment of PCM audio from /dev/video24 (or
whatever) that you can check later with your own ear.



My hypothesis is that once BTSC is forced once, autodetection of BTSC
will more likely work well for a good number of channel changes
thereafter.

I do not have enough analog stations to run a test.

Regards,
Andy

> Cheers
>
> Mark Lord



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

On 12/04/10 05:17 PM, Andy Walls wrote:
> On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
..
>> I wonder if this means that once the audio bug is present,
>> it remains present until the next time the driver is loaded/unloaded.
>
>> Which matches previous observations.
>> The fallback (hopefully) works around this, but there's still a bug
>> somewhere that is preventing the audio from working without the fallback.
..

Okay, the "fallback" works -- recordings made with it do have good audio.

And.. my hypothesis appears to be true thus far: once the audio fails,
requiring the fallback, it stays failed until the driver is reloaded.

Every subsequent recording made (after a "fallback") also experiences the fallback.
This is with a good channel, with good audio. Subsequent recordings using the
exact same channel.

Weird, eh. I wonder how to discover the real cause?

Good workaround, though! Thanks.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On 12/04/10 10:22 PM, Mark Lord wrote:
..
> Okay, the "fallback" works -- recordings made with it do have good audio.
>
> And.. my hypothesis appears to be true thus far: once the audio fails,
> requiring the fallback, it stays failed until the driver is reloaded.
>
> Every subsequent recording made (after a "fallback") also experiences the fallback.
> This is with a good channel, with good audio. Subsequent recordings
> using the exact same channel.
..

Mmm.. further to that: the problem went away as soon as I told
it to tune to a different channel. No more fallbacks (for now).
It can now even retune the original channel without fallbacks.

So.. tuning to a new channel appears to fix whatever the bad state was
that was triggering the fallbacks. Based on my sample of one, anyway. ;)

Now that it is behaving again, I cannot poke further until the next time
I'm lucky enough to be around when it fails.

> Weird, eh. I wonder how to discover the real cause?
> Good workaround, though! Thanks.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On 12/04/10 10:30 PM, Mark Lord wrote:
..
> Mmm.. further to that: the problem went away as soon as I told
> it to tune to a different channel. No more fallbacks (for now).
> It can now even retune the original channel without fallbacks.
>
> So.. tuning to a new channel appears to fix whatever the bad state was
> that was triggering the fallbacks. Based on my sample of one, anyway. ;)
..

Nope.. what that second email should have said, was
Changing channels in LiveTV, no fallbacks required
because the audio is already working from the initial fallback.

As soon as I quit from LiveTV, the next recording still needed
a new fallback. So the chip is still in some weird state where
auto-audio will continue to fail until I reload the module.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> On 12/04/10 10:30 PM, Mark Lord wrote:
> ..
> > Mmm.. further to that: the problem went away as soon as I told
> > it to tune to a different channel. No more fallbacks (for now).
> > It can now even retune the original channel without fallbacks.
> >
> > So.. tuning to a new channel appears to fix whatever the bad state was
> > that was triggering the fallbacks. Based on my sample of one, anyway. ;)
> ..
>
> Nope.. what that second email should have said, was
> Changing channels in LiveTV, no fallbacks required
> because the audio is already working from the initial fallback.
>
> As soon as I quit from LiveTV, the next recording still needed
> a new fallback. So the chip is still in some weird state where
> auto-audio will continue to fail until I reload the module.


Thansk you for all the testing and feedback.

At this point I'm going to brush up the fixes by properly incorporating
support for the cx18_av_g_tuner()/cx18_av_s_tuner() calls so that user
space can still influence the audio mode (mono, stereo, Lang1, lang2,
etc.) even when audio standard and format are forced. I'll have time on
Friday for this.



The *only* other thing I can think of, that I have control over, is the
PLL charge pump current in the analog tuner. Right now it is set to low
current to minimize phase noise when tuned to a channel. Perhaps
setting the PLL charge pump to high current while chaning the channel to
get a faster lock, and low current after a short time, will help get a
good SIF output from the analog tuner assembly sooner. Perhaps when I
have time....

Regards,
Andy



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

On 13/04/10 06:35 AM, Andy Walls wrote:
> On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
..
>> As soon as I quit from LiveTV, the next recording still needed
>> a new fallback. So the chip is still in some weird state where
>> auto-audio will continue to fail until I reload the module.
..
> The *only* other thing I can think of, that I have control over, is the
> PLL charge pump current in the analog tuner. Right now it is set to low
> current to minimize phase noise when tuned to a channel. Perhaps
> setting the PLL charge pump to high current while chaning the channel to
> get a faster lock, and low current after a short time, will help get a
> good SIF output from the analog tuner assembly sooner. Perhaps when I
> have time....
..

What's weird, is that things work most of the time.
But as soon as one fallback is needed, the chip then fails
continuously afterward, requiring fallback after fallback.
Until the driver is reloaded.

So to me, that suggests that perhaps some register has gotten corrupted,
or some part of the chip has gone wanky.

Perhaps if the driver could re-init more of the chip when tuning,
which might correct whatever bits/state happen to need fixing?

I might have a look later, and see if there are any obvious registers
that perhaps I could have it dump out prior to doing the fallback,
and then compare that state with a "good" tuning state. Or something.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On Tue, 2010-04-13 at 08:42 -0400, Mark Lord wrote:
> On 13/04/10 06:35 AM, Andy Walls wrote:
> > On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> ..
> >> As soon as I quit from LiveTV, the next recording still needed
> >> a new fallback. So the chip is still in some weird state where
> >> auto-audio will continue to fail until I reload the module.
> ..
> > The *only* other thing I can think of, that I have control over, is the
> > PLL charge pump current in the analog tuner. Right now it is set to low
> > current to minimize phase noise when tuned to a channel. Perhaps
> > setting the PLL charge pump to high current while chaning the channel to
> > get a faster lock, and low current after a short time, will help get a
> > good SIF output from the analog tuner assembly sooner. Perhaps when I
> > have time....
> ..
>
> What's weird, is that things work most of the time.
> But as soon as one fallback is needed, the chip then fails
> continuously afterward, requiring fallback after fallback.
> Until the driver is reloaded.

Hmmm. Interesting observation.

> So to me, that suggests that perhaps some register has gotten corrupted,
> or some part of the chip has gone wanky.
>
> Perhaps if the driver could re-init more of the chip when tuning,
> which might correct whatever bits/state happen to need fixing?

If needed, once we're in a forced mode, we could stop the
microcontroller, reload all of the microcontroller firmware, and restart
it. Kind of heavy handed, but it may work.


> I might have a look later, and see if there are any obvious registers
> that perhaps I could have it dump out prior to doing the fallback,
> and then compare that state with a "good" tuning state. Or something.


# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff

Keep in mind that some of these registers aren't settable and only read
out the state of various hardware blocks and functions.


Dumping the state of the microcontroller memory could also be done, but
I'd have to modify the driver to do it.
cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
doing that.

Regards,
Andy


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

On 13/04/10 09:45 PM, Andy Walls wrote:
..
> # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
>
> Keep in mind that some of these registers aren't settable and only read
> out the state of various hardware blocks and functions.
>
>
> Dumping the state of the microcontroller memory could also be done, but
> I'd have to modify the driver to do it.
> cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
> doing that.
..

Thanks. I'll have a go at that some night.

Meanwhile, tonight, audio failed.

The syslog shows the usual "fallback" messages,
but the audio consisted of very loud static, the kind
of noise one gets when the sample bits are all reversed.

While it was failing, I tried retuning, stopping/starting
the recording, etc.. nothing mattered. It wanted a reload
of the cx18 driver to cure it.

> If needed, once we're in a forced mode, we could stop the
> microcontroller, reload all of the microcontroller firmware, and restart
> it. Kind of heavy handed, but it may work.
..

Perhaps that's what is needed here.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On 14/04/10 12:32 AM, Mark Lord wrote:
..
> Thanks. I'll have a go at that some night.
>
> Meanwhile, tonight, audio failed.
..

Oh, I forgot to include this:

Apr 13 22:00:05 duke kernel: cx18-0: ================= START STATUS CARD #0 =================
Apr 13 22:00:05 duke kernel: cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: has radio
Apr 13 22:00:05 duke kernel: cx18-0 843: Video signal: present
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected format: NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified standard: NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified video input: Composite 7
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio mode: forced mode
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio standard: forced audio standard
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio muted: no
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio microcontroller: running
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio standard: BTSC
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B)
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audio input: Tuner (In8)
Apr 13 22:00:05 duke kernel: cx18-0 843: Preferred audio mode: stereo
Apr 13 22:00:05 duke kernel: cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44
Apr 13 22:00:05 duke kernel: tuner 2-0061: Tuner mode: analog TV
Apr 13 22:00:05 duke kernel: tuner 2-0061: Frequency: 531.25 MHz
Apr 13 22:00:05 duke kernel: tuner 2-0061: Standard: 0x0000b000
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Input: 1
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Volume: 0 dB
Apr 13 22:00:05 duke kernel: cx18-0: Video Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: Audio Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: GPIO: direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: cx18-0: Tuner: TV
Apr 13 22:00:05 duke kernel: cx18-0: Stream: MPEG-2 Program Stream
Apr 13 22:00:05 duke kernel: cx18-0: VBI Format: Private packet, IVTV format
Apr 13 22:00:05 duke kernel: cx18-0: Video: 720x480, 30 fps
Apr 13 22:00:05 duke kernel: cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 12000000, Peak 14500000
Apr 13 22:00:05 duke kernel: cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
Apr 13 22:00:05 duke kernel: cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
Apr 13 22:00:05 duke kernel: cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
Apr 13 22:00:05 duke kernel: cx18-0: Temporal Filter: Manual, 8
Apr 13 22:00:05 duke kernel: cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
Apr 13 22:00:05 duke kernel: cx18-0: Status flags: 0x00200001
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder VBI: status 0x0038, 5% of 1015 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Read MPEG/VBI: 190420992/476784 bytes
Apr 13 22:00:05 duke kernel: cx18-0: ================== END STATUS CARD #0 ==================

--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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

On 14/04/10 12:32 AM, Mark Lord wrote:
..
> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.
>
> While it was failing, I tried retuning, stopping/starting
> the recording, etc.. nothing mattered. It wanted a reload
> of the cx18 driver to cure it.
..

Since all of this happens rather randomly,
I'm beginning to more strongly suspect a race condition
somewhere in the driver.

Now, it's a rather large driver -- lots of complexity in that chip
-- so it will take me a while to sort through things.

But at first blush, I don't see any obvious locking around
the various read-modify-write sequences for the audio registers.

And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
which shouldn't be in play in this scenario).

Oddly, none of those spinlocks use _irq or _irq_save/restore,
which means they aren't providing any sort of mutual exclusion
against the interrupt handler.

But like I said, I'm only just beginning to look more closely now.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

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