Mailing List Archive

I've been experiencing a similar issue and have been ignoring it because my 2 cx18s have been fairly stable. Soon I'll try a recent v4l-dvb rev and see if the audio buzz is still there.

--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

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

On Mon, 2009-02-09 at 20:32 -0800, tbmail@hackthemainframe.com wrote:
> I'm experiencing some 'tinny'/fuzzy/interference on _some_ channels.
> The low channels (up to channel 8) work great -- the audio is clear.
> Every channel higher than that however as unclear, staticy sound. The
> audio isn't complete static, but sounds like there is interference.
> Here's a clip:
> http://www.terrybraun.net/fuzzyaudio.mpg

1. Are you using cable or an antenna?

2. Are you changing channels while a capture is ongoing or when it is
stopped?

3. With the tuner, tuner-simple, and cx18 debug (info, debug, i2c, and
mailbox) enabled, what is logged when you change channels and what is
logged when you start a capture?

4. It is really odd that 8 & 7 are OK but 9-13 are not. They are all 6
MHz apart (i.e. adjacent channels) in the High VHF band (we don't do a
tuner preseletor band switch to go from 7 to 13). Can you verify with
random channel switch patterns: 34, 4, 16, 6, 8, 10, 45, etc. that it is
consistently happening on channels 9 and above?

5. Is sound on the audio line in with Composite or SVideo always OK?

6. What does 'v4l2-ctl --log-status' report for staticy and non-staticy
channels?

7. What happens if you chanel to the same staticy channel several times
in succession?

8. What happens if you stop and restart the capture on the same channel
several times?


> I have a Hauppauge HVR-1600 with a Coax cable running directly to it.

> I'm using ivtv-tune -c (channel) to tune. I've tried the
> v4l2-ctl -d /dev/video0 --set-audio-input 0
> command but that does not fix it. I'm using the latest firmware and
> cx18 driver.

Just to clarify, the latest driver from the v4l-dvb repository, right?

9. With cx18 mailbox debugging turned on, does the driver load the APU
& CPU firmware twice, reseting the APU after each load?


Regards,
Andy

> The strange thing is, if I boot into Windows, and use the WinTV app,
> the audio is clear on all channels. Therefore, I don't think its the
> card that is the issue...


> Any help is appreciated.
>
> Terry



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

Andy,

For my setup, *I think* the audio buzz is on all NTSC channels. Sometimes the audio buzz is difficult to hear because the sound from the actual program masks the audio buzz away. Also, the volume of the audio buzz differs from channel to channel.

Thanks for providing some troubleshooting steps. Do I enable tuner, tuner-simple, and cx18 debug (info, debug, i2c, and mailbox) with this cx18 kernel option: debug=83?

Thanks.

--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

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

The only buzz I have on my tv card is a 15khz carrier signal from my sony trinitron, this is true under both Linux, XP and Window 7 Beta.  I use v4ctl to send my audio to my soundcard, which is connecterd to a Creative  "Digital IO Module (read transducer) from the soundcard pin plug to spdif, where it connects to a Yamaha multizone receiver and a pair of Klipsh Heresy III.s which respond up to 23 Khz.  If there were another buzz I'd hear it.  If you can hear that 15khz carrier, that may be your buzz, if you can hear it, your ears are still good.

I use a combination of ivtvctl, v4ctl to redirect audio and mplayer for the video out.
 Thank you,





Mark F. Kaufman



----- Original Message ----
From: . . <cdash@operamail.com>
To: ivtv-users@ivtvdriver.org
Sent: Saturday, February 14, 2009 6:52:16 PM
Subject: Re: [ivtv-users] CX18 audio interference

Andy,

For my setup, *I think* the audio buzz is on all NTSC channels. Sometimes the audio buzz is difficult to hear because the sound from the actual program masks the audio buzz away. Also, the volume of the audio buzz differs from channel to channel.

Thanks for providing some troubleshooting steps. Do I enable tuner, tuner-simple, and cx18 debug (info, debug, i2c, and mailbox) with this cx18 kernel option: debug=83?

Thanks.

--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

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





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

Sorry for the late reply.

> Just to clarify, the latest driver from the v4l-dvb repository, right?

Yes, latest from the v4l-dvb. I grabbed these from yesterday, March 20.


Answers to your questions:

1) Cable

2) I've tried both.

3) I don't really know how to set these, I tried setting debug=127,
I hope thats the same. Attached is my dmesg output (dmesg.txt), which
is:
-the loading of the module,
-tune to 14 (capture not started yet)
-start capture
-tuning to 3,4,5,8,9,11,20,8,41,6, and 8 (all while capture still running)
-stop capture

4) channel 8 seems perfect, 5 is really good (faint crackle every so often)
channels 2-4 aren't too bad, with just an odd bit of light static noise.
channel 9 isnt too bad, channel 10 is really bad, channel 11 is plain
terrible, 12 is bad, 13 isnt too bad, 14 not too bad, 15 not too bad,
16 & 17 both bad,...
some channels in the low twenties are not bad (faint crackle every so often)
higher twenties are pretty bad. thirties are mostly bad, as are 40's..

This is all consistent. Whether im tuning it while watching, or when its
stopped, or after I reload module, or first boot up.

5) Not using composite or svideo. only thing im using is my coax cable, no
line in. Everything works fine on Windows so I dont think its the hardware..

6) Channel 11 (staticy) (chan11.txt)
Channel 8 (fine) (chan8.txt)
Channel 20 (not bad, a bit of static) (chan20.txt)

7) stays staticy

8) stays staticy

9) Yes, from what I can tell from the dmesg output.

I am having what I believe is the same problem as the OP, namely static
in the audio of recordings from the analog tuner of the HVR-1600,
connected to cable. The static is worse on some channels than others. I
haven't done an exhaustive test, but channel 29 is really annoying,
while channels 3, 8 and 67 are tolerable.

I'd be happy to help debug the problem, but thought I'd first check if
it's already understood and being worked on. If not, I'll start
gathering data as described in the first reply to this thread.

Some details:
ASUS M3N78 PRO mobo
AMD Athlon X2 4850e CPU
Hauppauge HVR-1600 model 1199
Linux 2.6.28 64 bit (mythbuntu jaunty 9.04 beta)
v4l-dvb drivers from Apr 14 2009

I also have an older computer with:
ECS RS482-M754 mobo
AMD Sempron 3100+ CPU
Hauppauge PVR-150 model 1045
Linux 2.6.24 32 bit (mythbuntu hardy 8.04)
ivtv drivers provided by distro

I have swapped tuners and connections to confirm the problem is with the
card and/or driver. For example, when the PVR-150 is installed in the
new computer, there is no static in its channel 29 recordings.

So far, I've only used mythtv to troubleshoot, but I'm sure I can figure
out how to use your utils. I've got 23 years experience as a developer.

I don't have anything hooked up to the composite/s-video/audio inputs at
the moment. But if it would help, I'll scrounge up something to feed
into it.

Thanks,
Helen

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

Hi Andy,

Andy Walls wrote:

> First try:
>
> 1. (killing the mythbackend)
> 2. modprobe -r cx18
> 3. modprobe cx18
> 4. (restart the mythbackend)
>
> at see if that helps with the audio from the tuner.

It did not help.

> If it does, could you then try the cx18 driver from this repo:
>
> http://linuxtv.org/hg/~awalls/cx18-init-debug/
>
> and set things up so that
>
> options cx18 debug=15
>
> is set in /etc/modprobe.conf (or whatever you distro uses). I'd like to
> see the messages from the initialization of the cx18 driver at boot.
>
> I'm especially looking for any occurrance of the error messages in this
> patch:
>
> http://linuxtv.org/hg/~awalls/cx18-init-debug/rev/93828c207b80
>
> when the driver is loaded automatically at boot-up.

Should I still try the cx18-init-debug driver? Or could this indicate a
problem with the board? I don't have WinXP on this computer, but I do on
the old computer. Perhaps I should see if the board can tune and record
channel 29 in WinXP on the old computer?

FWIW, when I verified that modprobe -r cx18 did indeed remove the cx18
modules via lsmod, I was surprised to see some cx88 modules. I didn't
think the HVR-1600 needed them. Maybe for the IR device?

Thanks,
Helen

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

On Wed, 2009-04-15 at 16:37 -0400, faginbagin wrote:
> I am having what I believe is the same problem as the OP, namely static
> in the audio of recordings from the analog tuner of the HVR-1600,
> connected to cable. The static is worse on some channels than others. I
> haven't done an exhaustive test, but channel 29 is really annoying,
> while channels 3, 8 and 67 are tolerable.
>
> I'd be happy to help debug the problem, but thought I'd first check if
> it's already understood and being worked on. If not, I'll start
> gathering data as described in the first reply to this thread.
>
> Some details:
> ASUS M3N78 PRO mobo
> AMD Athlon X2 4850e CPU
> Hauppauge HVR-1600 model 1199
> Linux 2.6.28 64 bit (mythbuntu jaunty 9.04 beta)
> v4l-dvb drivers from Apr 14 2009
>
> I also have an older computer with:
> ECS RS482-M754 mobo
> AMD Sempron 3100+ CPU
> Hauppauge PVR-150 model 1045
> Linux 2.6.24 32 bit (mythbuntu hardy 8.04)
> ivtv drivers provided by distro
>
> I have swapped tuners and connections to confirm the problem is with the
> card and/or driver. For example, when the PVR-150 is installed in the
> new computer, there is no static in its channel 29 recordings.
>
> So far, I've only used mythtv to troubleshoot, but I'm sure I can figure
> out how to use your utils. I've got 23 years experience as a developer.
>
> I don't have anything hooked up to the composite/s-video/audio inputs at
> the moment. But if it would help, I'll scrounge up something to feed
> into it.

Helen,

First try:

1. (killing the mythbackend)
2. modprobe -r cx18
3. modprobe cx18
4. (restart the mythbackend)

at see if that helps with the audio from the tuner.

If it does, could you then try the cx18 driver from this repo:

http://linuxtv.org/hg/~awalls/cx18-init-debug/

and set things up so that

options cx18 debug=15

is set in /etc/modprobe.conf (or whatever you distro uses). I'd like to
see the messages from the initialization of the cx18 driver at boot.

I'm especially looking for any occurrance of the error messages in this
patch:

http://linuxtv.org/hg/~awalls/cx18-init-debug/rev/93828c207b80

when the driver is loaded automatically at boot-up.

Regards,
Andy


> Thanks,
> Helen



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

On Wed, 2009-04-15 at 18:21 -0400, faginbagin wrote:
> Hi Andy,
>
> Andy Walls wrote:
>
> > First try:
> >
> > 1. (killing the mythbackend)
> > 2. modprobe -r cx18
> > 3. modprobe cx18
> > 4. (restart the mythbackend)
> >
> > at see if that helps with the audio from the tuner.
>
> It did not help.

Hmmm. That was my litmus test for conclusively blaming the CX23418.
Now I'm not sure. (It could be an analog tuner driver problem too.)

Go to the directory where you ran the make for v4l-dvb and do this:

0. Configure MythTV to use 48 kbps audio for the analog tuner channels
1. kill the mythbackend
2. make unload
3. make unload
4. modprobe cx18 debug=15
5. restart the mythbackend


See if that helps the audio.

The "make unload" unloads all the v4l-dvb modules including the tuner
drivers. That way the "modprobe cx18" will load only the modules
needed.


> > If it does, could you then try the cx18 driver from this repo:
> >
> > http://linuxtv.org/hg/~awalls/cx18-init-debug/
> >
> > and set things up so that
> >
> > options cx18 debug=15
> >
> > is set in /etc/modprobe.conf (or whatever you distro uses). I'd like to
> > see the messages from the initialization of the cx18 driver at boot.
> >
> > I'm especially looking for any occurrance of the error messages in this
> > patch:
> >
> > http://linuxtv.org/hg/~awalls/cx18-init-debug/rev/93828c207b80
> >
> > when the driver is loaded automatically at boot-up.
>
> Should I still try the cx18-init-debug driver?

Yes, you can. I suspect your symtpoms will persist, but am not
extremely confident in that prediction.

First though, I'd like you to try and use the Audio Line-In (from a DVD
player or something) or FM radio (if your board has FM radio). The
latest v4l-dvb repo (from about yesterday) has a patch to make sure
Audio Line-In gets switched to properly in the cx18 driver.


You will probably want to use the following utilities as they make
troubleshooting easier than using MythTV:

1. mplayer

$ mplayer /dev/video0 -cache 8192
(plays the MPEG stream to window)


2. v4l2-ctl

$ v4l2-ctl -d /dev/video0 --log-status
$ v4l2-ctl -d /dev/video0 --list-inputs
$ v4l2-ctl -d /dev/video0 --set-input=2

3. ivtv-tune

$ ivtv-tune --help
$ ivtv-tune --list-freqtable
$ ivtv-tune -d /dev/video0 -t us-bcast --channel=9

4. ivtv-radio

$ ivtv-radio --help
$ ivtv-radio -d /dev/radio0 -i /dev/video24 -f 88.5




> Or could this indicate a
> problem with the board?

I doubt it.


> I don't have WinXP on this computer, but I do on
> the old computer. Perhaps I should see if the board can tune and record
> channel 29 in WinXP on the old computer?

I suspect it will, if you try.



> FWIW, when I verified that modprobe -r cx18 did indeed remove the cx18
> modules via lsmod, I was surprised to see some cx88 modules. I didn't
> think the HVR-1600 needed them. Maybe for the IR device?

The HVR-1600, which uses the CX23418, does not need them, nor does the
Zilog Z8F0811 IR chip on the HVR-1600.

The Conexant CX2388[0-3] chips used on other TV/video boards use the
cx88 modules. lspci -nnvv may show you what device (14f1:8800) needs
those modules. The cx88-alsa module also hooks into the ALSA sound
system drivers. It would be best to prevent those cx88 modules from
loading to eliminate them as a variable. (The /etc/modprobe.d/blacklist
file is how Fedora 10 prevents certain modules from loading.)


For reference, here are the driver initialization messages for my
HVR-1600MCE (FM radio and no IR), the list of relevant modules, and what
a 'v4l2-ctl --log-status' looks like for a tuned in NTSC UHF station
during a capture:

cx18: Start initialization, version 1.1.0
cx18-0: Initializing card 0
cx18-0: Autodetected Hauppauge card
cx18-0: cx23418 revision 01010000 (B)
tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1845764
tveeprom 1-0050: MAC address is 00-0D-FE-1C-2A-04
tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 1-0050: audio processor is CX23418 (idx 38)
tveeprom 1-0050: decoder processor is CX23418 (idx 31)
tveeprom 1-0050: has radio
cx18-0: Autodetected Hauppauge HVR-1600
cx18-0: Simultaneous Digital and Analog TV capture supported
tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
tda9887 2-0043: creating new instance
tda9887 2-0043: tda988[5/6/7] found
tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
tuner-simple 2-0061: creating new instance
tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB)
DVB: registering new adapter (cx18)
firmware: requesting v4l-cx23418-cpu.fw
MXL5005S: Attached at address 0x63
DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
cx18-0: DVB Frontend registered
cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
cx18-0: Registered device video32 for encoder YUV (16 x 128 kB)
cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB)
cx18-0: Registered device radio0 for encoder radio
cx18-0: Initialized card: Hauppauge HVR-1600
cx18: End initialization


Module Size Used by
cx18 112660 0
dvb_core 94108 1 cx18
i2c_algo_bit 13956 1 cx18
cx2341x 20100 1 cx18
tveeprom 21764 1 cx18
mxl5005s 40324 1
s5h1409 17284 1
tuner_simple 21012 1
tuner_types 25984 1 tuner_simple
cs5345 12764 1
tda9887 18564 1
tda8290 19336 0
tuner 28660 2
v4l2_common 22656 4 cx18,cx2341x,cs5345,tuner
videodev 43040 4 cx18,cs5345,tuner,v4l2_common
v4l1_compat 20996 1 videodev
v4l2_compat_ioctl32 17792 1 videodev
i2c_core 29216 12 cx18,i2c_algo_bit,tveeprom,mxl5005s,s5h1409,tuner_simple,cs5345,tda9887,tda8290,tuner,v4l2_common,i2c_piix4

(You may have different tuner chip drivers than the tda9887 and tda8290.)


Status Log:

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


Does your --log-status for a "staticy" sounding channel look different?


Regards,
Andy


> Thanks,
> Helen



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

Hi Andy,

> Go to the directory where you ran the make for v4l-dvb and do this:
>
> 0. Configure MythTV to use 48 kbps audio for the analog tuner channels
> 1. kill the mythbackend
> 2. make unload
> 3. make unload
> 4. modprobe cx18 debug=15
> 5. restart the mythbackend
>
> See if that helps the audio.

No joy :(

However, make unload did eliminate the cx88 modules and they didn't return.

> First though, I'd like you to try and use the Audio Line-In (from a DVD
> player or something) or FM radio (if your board has FM radio). The
> latest v4l-dvb repo (from about yesterday) has a patch to make sure
> Audio Line-In gets switched to properly in the cx18 driver.

I'll do this next, and use mplayer, etc. as you suggest.

Does it matter whether I use the utils from the source I downloaded
today, or the ivtv-utils binary package provided by ubuntu? The reason I
ask is because v4l2-sysfs-path.c wouldn't compile and other stuff didn't
build because I didn't have qmake installed. I do have v4l2-ctl and am
still trying to figure out how/where to make ivtv-tune.

>> Or could this indicate a
>> problem with the board?
>
> I doubt it.

I hope not, although I can still return/exchange it without a penalty if
that is the case.

> The Conexant CX2388[0-3] chips used on other TV/video boards use the
> cx88 modules. lspci -nnvv may show you what device (14f1:8800) needs
> those modules. The cx88-alsa module also hooks into the ALSA sound
> system drivers. It would be best to prevent those cx88 modules from
> loading to eliminate them as a variable. (The /etc/modprobe.d/blacklist
> file is how Fedora 10 prevents certain modules from loading.)

It's similar in debian/ubuntu. Looks like that's what I'll need to do.

> For reference, here are the driver initialization messages for my
> HVR-1600MCE (FM radio and no IR), the list of relevant modules, and what
> a 'v4l2-ctl --log-status' looks like for a tuned in NTSC UHF station
> during a capture:

Here's the equivalent stuff from my system:

dmesg output:
[26052.434536] cx18: Start initialization, version 1.1.0
[26052.434594] cx18-0: Initializing card 0
[26052.434598] cx18-0: Autodetected Hauppauge card
[26052.434647] cx18-0: info: base addr: 0xf4000000
[26052.434648] cx18-0: info: Enabling pci device
[26052.434662] cx18 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI 17
(level, low) -> IRQ 17
[26052.434671] cx18-0: info: cx23418 (rev 0) at 01:09.0, irq: 17,
latency: 64, memory: 0xf4000000
[26052.434673] cx18-0: info: attempting ioremap at 0xf4000000 len
0x04000000
[26052.437535] cx18-0: cx23418 revision 01010000 (B)
[26052.533078] cx18-0: info: GPIO initial dir: 0000cffe/0000ffff out:
00003001/00000000
[26052.533095] cx18-0: info: activating i2c...
[26052.613686] lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
[26052.613700] lirc_dev: lirc_register_plugin: sample_rate: 10
[26052.656944] tveeprom 0-0050: Hauppauge model 74041, rev C6B2, serial#
5405623
[26052.656948] tveeprom 0-0050: MAC address is 00-0D-FE-52-7B-B7
[26052.656950] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112,
type 50)
[26052.656952] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
[26052.656954] tveeprom 0-0050: audio processor is CX23418 (idx 38)
[26052.656955] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
[26052.656957] tveeprom 0-0050: has no radio, has IR receiver, has IR
transmitter
[26052.656959] cx18-0: Autodetected Hauppauge HVR-1600
[26052.656960] cx18-0: info: NTSC tuner detected
[26052.656961] cx18-0: Simultaneous Digital and Analog TV capture supported
[26052.766049] tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
[26052.770031] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[26052.790071] tuner-simple 1-0061: creating new instance
[26052.790074] tuner-simple 1-0061: type set to 50 (TCL 2002N)
[26052.790774] cx18-0: info: Allocate encoder MPEG stream: 64 x 32768
buffers (2048kB total)
[26052.790859] cx18-0: info: Allocate TS stream: 32 x 32768 buffers
(1024kB total)
[26052.790900] cx18-0: info: Allocate encoder YUV stream: 16 x 131072
buffers (2048kB total)
[26052.790950] cx18-0: info: Allocate encoder VBI stream: 20 x 51984
buffers (1015kB total)
[26052.791004] cx18-0: info: Allocate encoder PCM audio stream: 256 x
4096 buffers (1024kB total)
[26052.791181] cx18-0: info: Allocate encoder IDX stream: 32 x 32768
buffers (1024kB total)
[26052.791258] cx18-0: Registered device video0 for encoder MPEG (64 x
32 kB)
[26052.791261] DVB: registering new adapter (cx18)
[26052.808645] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-cpu.fw
[26052.923835] MXL5005S: Attached at address 0x63
[26052.923841] DVB: registering adapter 0 frontend 0 (Samsung S5H1409
QAM/8VSB Frontend)...
[26052.923912] cx18-0: DVB Frontend registered
[26052.923914] cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
[26052.923938] cx18-0: Registered device video32 for encoder YUV (16 x
128 kB)
[26052.923957] cx18-0: Registered device vbi0 for encoder VBI (20 x
51984 bytes)
[26052.923978] cx18-0: Registered device video24 for encoder PCM audio
(256 x 4 kB)
[26052.923981] cx18-0: Initialized card: Hauppauge HVR-1600
[26052.924028] cx18: End initialization

lsmod output:
Module Size Used by
mxl5005s 45316 1
s5h1409 18308 1
tuner_simple 23956 1
tuner_types 26240 1 tuner_simple
cs5345 12636 1
tuner 33776 1
cx18 124708 0
dvb_core 111404 1 cx18
cx2341x 23300 1 cx18
v4l2_common 26880 4 cs5345,tuner,cx18,cx2341x
videodev 49184 4 cs5345,tuner,cx18,v4l2_common
v4l1_compat 24068 1 videodev
v4l2_compat_ioctl32 19712 1 videodev
tveeprom 23556 1 cx18
binfmt_misc 18572 1
ppdev 16904 0
bridge 63904 0
stp 11140 1 bridge
bnep 22912 2
lirc_i2c 18948 0
lirc_dev 22088 1 lirc_i2c
video 29204 0
output 11648 1 video
input_polldev 12688 0
jfs 197200 1
it87 35352 0
hwmon_vid 12160 1 it87
adm1021 22064 0
lp 19588 0
parport 49584 2 ppdev,lp
snd_hda_intel 557364 0
snd_pcm_oss 52352 0
snd_mixer_oss 24960 1 snd_pcm_oss
snd_pcm 99336 2 snd_hda_intel,snd_pcm_oss
snd_seq_dummy 11524 0
snd_seq_oss 41984 0
snd_seq_midi 15744 0
snd_rawmidi 33920 1 snd_seq_midi
snd_seq_midi_event 16512 2 snd_seq_oss,snd_seq_midi
snd_seq 66272 6
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer 34064 2 snd_pcm,snd_seq
snd_seq_device 16276 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
i2c_algo_bit 15364 1 cx18
snd 78792 9
snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore 16800 1 snd
snd_page_alloc 18704 2 snd_hda_intel,snd_pcm
psmouse 64028 0
serio_raw 14468 0
pcspkr 11136 0
k8temp 13440 0
nvidia 8123768 26
hid_bright 10624 0
usbhid 47040 1 hid_bright
forcedeth 68368 0
floppy 75816 0
fbcon 49792 0
tileblit 11264 1 fbcon
font 17024 1 fbcon
bitblit 14464 1 fbcon
softcursor 10368 1 bitblit

v4l2-ctl output (Note, this was after mythbackend stopped recording, not
during, I was compiling as the recording was in progress):

Status Log:

[29384.798135] cx18-0: ================= START STATUS CARD #0
=================
[29384.798139] cx18-0: Version: 1.1.0 Card: Hauppauge HVR-1600
[29384.831826] tveeprom 0-0050: Hauppauge model 74041, rev C6B2,
serial# 5405623
[29384.831829] tveeprom 0-0050: MAC address is 00-0D-FE-52-7B-B7
[29384.831831] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx
112, type 50)
[29384.831833] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
[29384.831835] tveeprom 0-0050: audio processor is CX23418 (idx 38)
[29384.831837] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
[29384.831838] tveeprom 0-0050: has no radio, has IR receiver, has
IR transmitter
[29384.831844] cx18-0 843: Video signal: present
[29384.831845] cx18-0 843: Detected format: NTSC-M
[29384.831847] cx18-0 843: Specified standard: NTSC-M
[29384.831848] cx18-0 843: Specified video input: Composite 7
[29384.831849] cx18-0 843: Specified audioclock freq: 48000 Hz
[29384.831859] cx18-0 843: Detected audio mode: stereo
[29384.831860] cx18-0 843: Detected audio standard: BTSC
[29384.831862] cx18-0 843: Audio muted: no
[29384.831863] cx18-0 843: Audio microcontroller: running
[29384.831864] cx18-0 843: Configured audio standard: automatic
detection
[29384.831866] cx18-0 843: Configured audio system: BTSC
[29384.831867] cx18-0 843: Specified audio input: Tuner (In8)
[29384.831869] cx18-0 843: Preferred audio mode: stereo
[29384.831871] cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001,
value 0x00003001
[29384.831873] tuner 1-0061: Tuner mode: analog TV
[29384.831875] tuner 1-0061: Frequency: 253.25 MHz
[29384.831876] tuner 1-0061: Standard: 0x0000b000
[29384.833601] cs5345 0-004c: Input: 1
[29384.833603] cs5345 0-004c: Volume: 0 dB
[29384.833604] cx18-0: Video Input: Tuner 1
[29384.833606] cx18-0: Audio Input: Tuner 1
[29384.833608] cx18-0: GPIO: direction 0x00003001, value 0x00003001
[29384.833609] cx18-0: Tuner: TV
[29384.833611] cx18-0: Stream: MPEG-2 DVD-compatible Stream
[29384.833614] cx18-0: VBI Format: Private packet, IVTV format
[29384.833617] cx18-0: Video: 720x480, 30 fps
[29384.833620] cx18-0: Video: MPEG-2, 4x3, Variable Bitrate,
2000000, Peak 3500000
[29384.833623] cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
[29384.833626] cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 256 kbps,
Stereo, No Emphasis, No CRC
[29384.833629] cx18-0: Spatial Filter: Manual, Luma 1D Horizontal,
Chroma 1D Horizontal, 0
[29384.833631] cx18-0: Temporal Filter: Manual, 8
[29384.833634] cx18-0: Median Filter: Off, Luma [0, 255], Chroma
[0, 255]
[29384.833636] cx18-0: Status flags: 0x00200001
[29384.833638] cx18-0: Stream encoder MPEG: status 0x0000, 0% of
2048 KiB (64 buffers) in use
[29384.833641] cx18-0: Stream encoder YUV: status 0x0000, 0% of 2048
KiB (16 buffers) in use
[29384.833644] cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015
KiB (20 buffers) in use
[29384.833647] cx18-0: Stream encoder PCM audio: status 0x0000, 0%
of 1024 KiB (256 buffers) in use
[29384.833649] cx18-0: Read MPEG/VBI: 66054144/0 bytes
[29384.833651] cx18-0: ================== END STATUS CARD #0
==================

The differences I see are:
- I've got VBI enabled, even though I don't expect CCs at this time.
- I'm using DVD compatible and you're using MPEG-PS.
- I'm using much lower bitrates for video vbr=2 mbps and peak=3.5 mbps,
these work well with my PVR-150 and keep recordings down to around 1GB/hour.
- I'm using a higher bitrate for audio 256 kbps vs 224.
- tuner frequency and standard are different. I'm tuning to channel 29
on cable. I'm guessing you're tuning to a broadcast channel?

Perhaps I should try using your parameters, including disabling VBI,
still using cable? Broadcast is out of the question for me.

Anyway, I'm now going to hook up the DVD player and see what happens.

One last thing. I had trimmed the dmesg output after "End
initialization", but I thought you might want to see the debug output
during the recording, including the firmware loading. Actually, there
were two recordings during this time, a few minutes of a recording on
channel 7 I interrupted when I stopped and restarted mythbackend, and
the recording on the problem channel 29. It follows my signature. Hope
you don't mind another 167 lines!

Helen

[26052.964096] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
[26052.989319] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-apu.fw
[26053.009007] cx18-0: info: load segment a00000-a07fff
[26053.031785] cx18-0: info: load segment ae0000-ae00ff
[26053.031964] cx18-0: info: load segment b00000-b1a65f
[26053.107122] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
(141200 bytes)
[26053.111865] cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0
(Release 2007/03/12)
[26053.111867] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
[26053.316027] cx18-0: api: CX18_CPU_DEBUG_PEEK32 cmd 0x20000003
args 0x00000000
[26053.316086] cx18-0: api: CX18_APU_START cmd 0x10000001 args
0x000000b9 0x00000000
[26053.317251] cx18-0: api: CX18_APU_RESETAI cmd 0x10000005 args
[26053.317681] cx18-0: api: CX18_APU_STOP cmd 0x10000002 args
0x00000000
[26053.320796] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-cpu.fw
[26053.461133] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-apu.fw
[26053.465489] cx18-0: info: load segment a00000-a07fff
[26053.488190] cx18-0: info: load segment ae0000-ae00ff
[26053.488370] cx18-0: info: load segment b00000-b1a65f
[26053.569182] cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0
(Release 2007/03/12)
[26053.772019] cx18-0: api: CX18_CPU_DEBUG_PEEK32 cmd 0x20000003
args 0x00000000
[26053.772075] cx18-0: api: CX18_APU_START cmd 0x10000001 args
0x000000b9 0x00000000
[26053.773248] cx18-0: api: CX18_APU_RESETAI cmd 0x10000005 args
[26053.773678] cx18-0: api: CX18_APU_STOP cmd 0x10000002 args
0x00000000
[26053.773744] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-dig.fw
[26053.966498] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
[26053.966541] cx18-0: info: Changing input from 1 to 0
[26053.966543] cx18-0: info: Mute
[26053.966545] cx18-0 843: info: decoder set video input 7, audio input 8
[26053.967472] cx18-0 843: info: decoder set video input 7, audio input 8
[26053.967538] cx18-0: info: Unmute
[26053.967539] cx18-0: info: Switching standard to 1000.
[26053.967541] cx18-0 843: info: changing video std to fmt 1
[26053.967556] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26053.967557] cx18-0 843: info: PLL = 107.999999 MHz
[26053.967559] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26053.967560] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26053.967562] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26053.967564] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26053.968319] cx18-0: info: Mute
[26053.968320] cx18-0: info: v4l2 ioctl: set frequency 1076
[26053.969046] cx18-0: info: Unmute
[26102.188063] cx18-0: info: Input unchanged
[26102.188068] cx18-0: info: Switching standard to b000.
[26102.188070] cx18-0 843: info: changing video std to fmt 1
[26102.188086] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26102.188088] cx18-0 843: info: PLL = 107.999999 MHz
[26102.188089] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26102.188090] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26102.188092] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26102.188094] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26102.190696] cx18-0: info: Input unchanged
[26102.191473] cx18-0: info: Mute
[26102.191476] cx18-0: info: v4l2 ioctl: set frequency 2804
[26102.192208] cx18-0: info: Unmute
[26106.048921] cx18-0: info: Input unchanged
[26106.050874] cx18-0: info: Mute
[26106.050877] cx18-0: info: v4l2 ioctl: set frequency 2804
[26106.051608] cx18-0: info: Unmute
[26106.069672] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
0x20020011 args 0xffffffff 0x000000c9
[26106.070328] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
args 0xffffffff 0x00000000 0x001e8480 0x00004e20 0x00000000
[26106.070426] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
0x20020012 args 0xffffffff 0x0000000e
[26106.070477] cx18-0: info: disabled insertion of sliced VBI data into
the MPEG stream
[26106.070529] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26106.070531] cx18-0 843: info: PLL = 107.999999 MHz
[26106.070533] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26106.070534] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26106.070536] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26106.070538] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26106.070651] cx18-0: info: disabled insertion of sliced VBI data into
the MPEG stream
[26106.070711] cx18-0: info: Start encoder stream encoder MPEG
[26106.070714] cx18-0: api: CX18_CREATE_TASK cmd 0x40000001 args
0x20020000
[26106.070768] cx18-0: api: CX18_CPU_SET_CHANNEL_TYPE cmd 0x20020001
args 0x00000000 0x00000001
[26106.070819] cx18-0: api: CX18_CPU_SET_VER_CROP_LINE cmd 0x2002001b
args 0x00000000 0x00000000
[26106.070871] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000003 0x00000001
[26106.070925] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000008 0x00000000
[26106.070977] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000004 0x00000001
[26106.071029] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x0000000c
[26106.071077] cx18-0: api: CX18_CPU_SET_CAPTURE_LINE_NO cmd
0x20020017 args 0x00000000 0x00000138 0x00000139
[26106.071134] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26106.071135] cx18-0 843: info: PLL = 107.999999 MHz
[26106.071137] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26106.071138] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26106.071140] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26106.071142] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26106.071237] cx18-0: info: Setup VBI h: 0 lines 120012 bpl 272 fr 1
b0f0b0f0 a0e0a0e0
[26106.071240] cx18-0: api: CX18_CPU_SET_RAW_VBI_PARAM cmd 0x20020016
args 0x00000000 0x00120012 0x00000110 0x00000001 0xb0f0b0f0 0xa0e0a0e0
[26106.368023] cx18-0: api: CX18_CPU_SET_INDEXTABLE cmd 0x20020010
args 0x00000000
[26106.368078] cx18-0: api: CX18_CPU_SET_VIDEO_IN cmd 0x20020004
args 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
[26106.368147] cx18-0: api: CX18_CPU_SET_VIDEO_RESOLUTION cmd
0x20020006 args 0x00000000 0x000002d0 0x000001e0
[26106.368210] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
0x20020012 args 0x00000000 0x0000000e
[26106.368265] cx18-0: api: CX18_CPU_SET_ASPECT_RATIO cmd 0x2002001e
args 0x00000000 0x00000002
[26106.368317] cx18-0: api: CX18_CPU_SET_GOP_STRUCTURE cmd 0x2002001c
args 0x00000000 0x0000000f 0x00000003
[26106.368369] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
0x20020011 args 0x00000000 0x000000c9
[26106.368428] cx18-0: api: CX18_CPU_SET_AUDIO_MUTE cmd 0x20020014
args 0x00000000 0x00000000
[26106.368494] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
args 0x00000000 0x00000000 0x001e8480 0x00004e20 0x00000000
[26106.370230] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000001 0x00000000 0x00000000
[26106.370286] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000000 0x00000001 0x00000008
[26106.370339] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000002 0x00000000 0x00000000
[26106.370396] cx18-0: api: CX18_CPU_SET_MEDIAN_CORING cmd 0x2002000e
args 0x00000000 0x00000000 0x000000ff 0x00000000 0x000000ff
[26106.370457] cx18-0: api: CX18_CPU_SET_SPATIAL_FILTER_TYPE cmd
0x2002000c args 0x00000000 0x00000001 0x00000001
[26106.370513] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000001 0x00000000 0x00000000
[26106.370566] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000000 0x00000001 0x00000008
[26106.370620] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000002 0x00000000 0x00000000
[26106.370674] cx18-0: api: CX18_CPU_SET_SKIP_INPUT_FRAME cmd
0x2002001f args 0x00000000 0x00000000
[26106.370724] cx18-0: api: CX18_CPU_SET_VIDEO_MUTE cmd 0x20020013
args 0x00000000 0x00808000
[26106.370774] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000007 0x00000000 0x00000000
[26106.370832] cx18-0: api: CX18_CPU_DE_SET_MDL_ACK cmd 0x20040002
args 0x00000000 0x00dc0c40 0x00dc0c48
[26106.377264] cx18-0: api: CX18_CPU_CAPTURE_START cmd 0x20020002
args 0x00000000
[26192.902880] cx18-0: info: close stopping capture
[26192.902883] cx18-0: info: Stop Capture
[26192.902886] cx18-0: api: CX18_CPU_CAPTURE_STOP cmd 0x20020003
args 0x00000000 0x00000001
[26193.200037] cx18-0: api: CX18_CPU_DE_RELEASE_MDL cmd 0x20040006
args 0x00000000
[26193.500037] cx18-0: api: CX18_DESTROY_TASK cmd 0x40000002 args
0x00000000
[26252.392930] cx18-0: info: Input unchanged
[26252.394922] cx18-0: info: Mute
[26252.394926] cx18-0: info: v4l2 ioctl: set frequency 4052
[26252.395656] cx18-0: info: Unmute
[26252.413112] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
args 0xffffffff 0x00000000 0x001e8480 0x0000222e 0x00000000
[26252.413310] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26252.413314] cx18-0 843: info: PLL = 107.999999 MHz
[26252.413315] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26252.413317] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26252.413318] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26252.413321] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26252.413494] cx18-0: info: Start encoder stream encoder MPEG
[26252.413497] cx18-0: api: CX18_CREATE_TASK cmd 0x40000001 args
0x20020000
[26252.413549] cx18-0: api: CX18_CPU_SET_CHANNEL_TYPE cmd 0x20020001
args 0x00000000 0x00000001
[26252.413600] cx18-0: api: CX18_CPU_SET_VER_CROP_LINE cmd 0x2002001b
args 0x00000000 0x00000000
[26252.413652] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000003 0x00000001
[26252.413709] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000008 0x00000000
[26252.420032] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000004 0x00000001
[26252.420094] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x0000000c
[26252.420147] cx18-0: api: CX18_CPU_SET_CAPTURE_LINE_NO cmd
0x20020017 args 0x00000000 0x00000138 0x00000139
[26252.420209] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
[26252.420210] cx18-0 843: info: PLL = 107.999999 MHz
[26252.420212] cx18-0 843: info: PLL/8 = 13.499999 MHz
[26252.420213] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
[26252.420215] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
[26252.420217] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
1, comb 0x66, sc 0x087c1f
[26252.420315] cx18-0: info: Setup VBI h: 0 lines 120012 bpl 272 fr 1
b0f0b0f0 a0e0a0e0
[26252.420318] cx18-0: api: CX18_CPU_SET_RAW_VBI_PARAM cmd 0x20020016
args 0x00000000 0x00120012 0x00000110 0x00000001 0xb0f0b0f0 0xa0e0a0e0
[26252.720014] cx18-0: api: CX18_CPU_SET_INDEXTABLE cmd 0x20020010
args 0x00000000
[26252.720077] cx18-0: api: CX18_CPU_SET_VIDEO_IN cmd 0x20020004
args 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
[26252.720151] cx18-0: api: CX18_CPU_SET_VIDEO_RESOLUTION cmd
0x20020006 args 0x00000000 0x000002d0 0x000001e0
[26252.720217] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
0x20020012 args 0x00000000 0x0000000e
[26252.720270] cx18-0: api: CX18_CPU_SET_ASPECT_RATIO cmd 0x2002001e
args 0x00000000 0x00000002
[26252.720322] cx18-0: api: CX18_CPU_SET_GOP_STRUCTURE cmd 0x2002001c
args 0x00000000 0x0000000f 0x00000003
[26252.720374] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
0x20020011 args 0x00000000 0x000000c9
[26252.720440] cx18-0: api: CX18_CPU_SET_AUDIO_MUTE cmd 0x20020014
args 0x00000000 0x00000000
[26252.720516] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
args 0x00000000 0x00000000 0x001e8480 0x0000222e 0x00000000
[26252.720578] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000001 0x00000000 0x00000000
[26252.720796] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000000 0x00000001 0x00000008
[26252.720851] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000002 0x00000000 0x00000000
[26252.720907] cx18-0: api: CX18_CPU_SET_MEDIAN_CORING cmd 0x2002000e
args 0x00000000 0x00000000 0x000000ff 0x00000000 0x000000ff
[26252.720968] cx18-0: api: CX18_CPU_SET_SPATIAL_FILTER_TYPE cmd
0x2002000c args 0x00000000 0x00000001 0x00000001
[26252.721024] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000001 0x00000000 0x00000000
[26252.721078] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000000 0x00000001 0x00000008
[26252.721132] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
args 0x00000000 0x00000002 0x00000000 0x00000000
[26252.721188] cx18-0: api: CX18_CPU_SET_SKIP_INPUT_FRAME cmd
0x2002001f args 0x00000000 0x00000000
[26252.721237] cx18-0: api: CX18_CPU_SET_VIDEO_MUTE cmd 0x20020013
args 0x00000000 0x00808000
[26252.721287] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
0x20020015 args 0x00000000 0x00000007 0x00000000 0x00000000
[26252.721345] cx18-0: api: CX18_CPU_DE_SET_MDL_ACK cmd 0x20040002
args 0x00000000 0x00dc0c40 0x00dc0c48
[26252.725479] cx18-0: api: CX18_CPU_CAPTURE_START cmd 0x20020002
args 0x00000000
[26461.273809] cx18-0: info: close stopping capture
[26461.273812] cx18-0: info: Stop Capture
[26461.273815] cx18-0: api: CX18_CPU_CAPTURE_STOP cmd 0x20020003
args 0x00000000 0x00000001
[26461.572026] cx18-0: api: CX18_CPU_DE_RELEASE_MDL cmd 0x20040006
args 0x00000000
[26461.872020] cx18-0: api: CX18_DESTROY_TASK cmd 0x40000002 args
0x00000000


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

On Wed, 2009-04-15 at 22:48 -0400, faginbagin wrote:
> Hi Andy,
>
> > Go to the directory where you ran the make for v4l-dvb and do this:
> >
> > 0. Configure MythTV to use 48 kbps audio for the analog tuner channels
> > 1. kill the mythbackend
> > 2. make unload
> > 3. make unload
> > 4. modprobe cx18 debug=15
> > 5. restart the mythbackend
> >
> > See if that helps the audio.
>
> No joy :(
>
> However, make unload did eliminate the cx88 modules and they didn't return.
>
> > First though, I'd like you to try and use the Audio Line-In (from a DVD
> > player or something) or FM radio (if your board has FM radio). The
> > latest v4l-dvb repo (from about yesterday) has a patch to make sure
> > Audio Line-In gets switched to properly in the cx18 driver.
>
> I'll do this next, and use mplayer, etc. as you suggest.
>
> Does it matter whether I use the utils from the source I downloaded
> today, or the ivtv-utils binary package provided by ubuntu? The reason I
> ask is because v4l2-sysfs-path.c wouldn't compile and other stuff didn't
> build because I didn't have qmake installed. I do have v4l2-ctl and am
> still trying to figure out how/where to make ivtv-tune.

You can certainly use the v4l2-ctl that came with your distro.

You don't need ivtv-tune, but I like it because you can use channel
numbers instead of frequencies to change channels (while mplayer is
running!). v4l2-ctl makes you use a frequency IIRC.

ivtv-tune should be in the ivtv-utils-1.0.3 tarball from the
ivtvdriver.org website. There's a chicken-and-egg problem building it
though. It won't build until you install the ivtv headers. It won't
install the ivtv headers until you 'make install', but that requires
everything to build first... *sigh*. The work around is to just move
the header in place by hand to wherever make install would have put them
and then build.


>
> >> Or could this indicate a
> >> problem with the board?
> >
> > I doubt it.
>
> I hope not, although I can still return/exchange it without a penalty if
> that is the case.

I don't think it's a board problem. I think it's an incoming signal
problem. If your cable signals on some channels are so strong that they
start overdriving the analog receiver front end (bumping into non-linear
regions of the amplifiers), then you can get intermodulation products
which will show up as noise on other channels. The 3rd order
intermodulation products can be particularly strong at frequencies
*higher* than the two or more strong channels that caused them.


I think I have detected the symptoms you describe on broadcast channel
32 (579.25 MHz) on my setup with my HVR-1600. The static is slight, but
it is noticable and consistent.

There are relatively few strong over the air station where I am at. It
shouldn't take me too long to build up a spreadsheet of all the possible
intermodulation products that pairs of strong stations below channel 32
could create on channel 32's frequency band.

If I'm right, then attenuationing the strong stations with an external
attenuatior or filter should make the static go away.

Since I can reproduce this, I'll try and debug this without you going
through too many hoops. Hopefully the symptoms won't go away. Over the
air propagation can be weather and time of day dependent...


> > For reference, here are the driver initialization messages for my
> > HVR-1600MCE (FM radio and no IR), the list of relevant modules, and what
> > a 'v4l2-ctl --log-status' looks like for a tuned in NTSC UHF station
> > during a capture:
>
> Here's the equivalent stuff from my system:
>
> dmesg output:
> [26052.434536] cx18: Start initialization, version 1.1.0
> [26052.434594] cx18-0: Initializing card 0
> [26052.434598] cx18-0: Autodetected Hauppauge card
> [26052.434647] cx18-0: info: base addr: 0xf4000000
> [26052.434648] cx18-0: info: Enabling pci device
> [26052.434662] cx18 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI 17
> (level, low) -> IRQ 17
> [26052.434671] cx18-0: info: cx23418 (rev 0) at 01:09.0, irq: 17,
> latency: 64, memory: 0xf4000000
> [26052.434673] cx18-0: info: attempting ioremap at 0xf4000000 len
> 0x04000000
> [26052.437535] cx18-0: cx23418 revision 01010000 (B)
> [26052.533078] cx18-0: info: GPIO initial dir: 0000cffe/0000ffff out:
> 00003001/00000000
> [26052.533095] cx18-0: info: activating i2c...
> [26052.613686] lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
> [26052.613700] lirc_dev: lirc_register_plugin: sample_rate: 10
> [26052.656944] tveeprom 0-0050: Hauppauge model 74041, rev C6B2, serial#
> 5405623
> [26052.656948] tveeprom 0-0050: MAC address is 00-0D-FE-52-7B-B7
> [26052.656950] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112,
> type 50)
> [26052.656952] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
> [26052.656954] tveeprom 0-0050: audio processor is CX23418 (idx 38)
> [26052.656955] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
> [26052.656957] tveeprom 0-0050: has no radio, has IR receiver, has IR
> transmitter
> [26052.656959] cx18-0: Autodetected Hauppauge HVR-1600
> [26052.656960] cx18-0: info: NTSC tuner detected
> [26052.656961] cx18-0: Simultaneous Digital and Analog TV capture supported
> [26052.766049] tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> [26052.770031] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> [26052.790071] tuner-simple 1-0061: creating new instance
> [26052.790074] tuner-simple 1-0061: type set to 50 (TCL 2002N)
> [26052.790774] cx18-0: info: Allocate encoder MPEG stream: 64 x 32768
> buffers (2048kB total)
> [26052.790859] cx18-0: info: Allocate TS stream: 32 x 32768 buffers
> (1024kB total)
> [26052.790900] cx18-0: info: Allocate encoder YUV stream: 16 x 131072
> buffers (2048kB total)
> [26052.790950] cx18-0: info: Allocate encoder VBI stream: 20 x 51984
> buffers (1015kB total)
> [26052.791004] cx18-0: info: Allocate encoder PCM audio stream: 256 x
> 4096 buffers (1024kB total)
> [26052.791181] cx18-0: info: Allocate encoder IDX stream: 32 x 32768
> buffers (1024kB total)
> [26052.791258] cx18-0: Registered device video0 for encoder MPEG (64 x
> 32 kB)
> [26052.791261] DVB: registering new adapter (cx18)
> [26052.808645] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-cpu.fw
> [26052.923835] MXL5005S: Attached at address 0x63
> [26052.923841] DVB: registering adapter 0 frontend 0 (Samsung S5H1409
> QAM/8VSB Frontend)...
> [26052.923912] cx18-0: DVB Frontend registered
> [26052.923914] cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
> [26052.923938] cx18-0: Registered device video32 for encoder YUV (16 x
> 128 kB)
> [26052.923957] cx18-0: Registered device vbi0 for encoder VBI (20 x
> 51984 bytes)
> [26052.923978] cx18-0: Registered device video24 for encoder PCM audio
> (256 x 4 kB)
> [26052.923981] cx18-0: Initialized card: Hauppauge HVR-1600
> [26052.924028] cx18: End initialization
>
> lsmod output:
> Module Size Used by
> mxl5005s 45316 1
> s5h1409 18308 1
> tuner_simple 23956 1
> tuner_types 26240 1 tuner_simple
> cs5345 12636 1
> tuner 33776 1
> cx18 124708 0
> dvb_core 111404 1 cx18
> cx2341x 23300 1 cx18
> v4l2_common 26880 4 cs5345,tuner,cx18,cx2341x
> videodev 49184 4 cs5345,tuner,cx18,v4l2_common
> v4l1_compat 24068 1 videodev
> v4l2_compat_ioctl32 19712 1 videodev
> tveeprom 23556 1 cx18
> binfmt_misc 18572 1
> ppdev 16904 0
> bridge 63904 0
> stp 11140 1 bridge
> bnep 22912 2
> lirc_i2c 18948 0
> lirc_dev 22088 1 lirc_i2c
> video 29204 0
> output 11648 1 video
> input_polldev 12688 0
> jfs 197200 1
> it87 35352 0
> hwmon_vid 12160 1 it87
> adm1021 22064 0
> lp 19588 0
> parport 49584 2 ppdev,lp
> snd_hda_intel 557364 0
> snd_pcm_oss 52352 0
> snd_mixer_oss 24960 1 snd_pcm_oss
> snd_pcm 99336 2 snd_hda_intel,snd_pcm_oss
> snd_seq_dummy 11524 0
> snd_seq_oss 41984 0
> snd_seq_midi 15744 0
> snd_rawmidi 33920 1 snd_seq_midi
> snd_seq_midi_event 16512 2 snd_seq_oss,snd_seq_midi
> snd_seq 66272 6
> snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
> snd_timer 34064 2 snd_pcm,snd_seq
> snd_seq_device 16276 5
> snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
> i2c_algo_bit 15364 1 cx18
> snd 78792 9
> snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> soundcore 16800 1 snd
> snd_page_alloc 18704 2 snd_hda_intel,snd_pcm
> psmouse 64028 0
> serio_raw 14468 0
> pcspkr 11136 0
> k8temp 13440 0
> nvidia 8123768 26
> hid_bright 10624 0
> usbhid 47040 1 hid_bright
> forcedeth 68368 0
> floppy 75816 0
> fbcon 49792 0
> tileblit 11264 1 fbcon
> font 17024 1 fbcon
> bitblit 14464 1 fbcon
> softcursor 10368 1 bitblit

This all looks OK, after a cursory glance. You may want to unload
lirc_i2c while testing, just to eliminate any possible unknown due to
lirc.. lirc_i2c is going to use the first I2C master of the CX23418 to
talk to the Z8 IR microcontroller chip. The analog tuner commands are
sent on the second I2C master of the CX23418 chip.



> v4l2-ctl output (Note, this was after mythbackend stopped recording, not
> during, I was compiling as the recording was in progress):
>
> Status Log:
>
> [29384.798135] cx18-0: ================= START STATUS CARD #0
> =================
> [29384.798139] cx18-0: Version: 1.1.0 Card: Hauppauge HVR-1600
> [29384.831826] tveeprom 0-0050: Hauppauge model 74041, rev C6B2,
> serial# 5405623
> [29384.831829] tveeprom 0-0050: MAC address is 00-0D-FE-52-7B-B7
> [29384.831831] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx
> 112, type 50)
> [29384.831833] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
> [29384.831835] tveeprom 0-0050: audio processor is CX23418 (idx 38)
> [29384.831837] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
> [29384.831838] tveeprom 0-0050: has no radio, has IR receiver, has
> IR transmitter
> [29384.831844] cx18-0 843: Video signal: present
> [29384.831845] cx18-0 843: Detected format: NTSC-M
> [29384.831847] cx18-0 843: Specified standard: NTSC-M
> [29384.831848] cx18-0 843: Specified video input: Composite 7
> [29384.831849] cx18-0 843: Specified audioclock freq: 48000 Hz
> [29384.831859] cx18-0 843: Detected audio mode: stereo
> [29384.831860] cx18-0 843: Detected audio standard: BTSC
> [29384.831862] cx18-0 843: Audio muted: no
> [29384.831863] cx18-0 843: Audio microcontroller: running
> [29384.831864] cx18-0 843: Configured audio standard: automatic
> detection
> [29384.831866] cx18-0 843: Configured audio system: BTSC
> [29384.831867] cx18-0 843: Specified audio input: Tuner (In8)
> [29384.831869] cx18-0 843: Preferred audio mode: stereo

The analog SIF digitizer and broadcast decoder looks happy with the
sound IF.


> [29384.831871] cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001,
> value 0x00003001
> [29384.831873] tuner 1-0061: Tuner mode: analog TV
> [29384.831875] tuner 1-0061: Frequency: 253.25 MHz

253.25 MHz is cable channel 29. It's frequency is between US broadcast
channel 13 (211.25 MHz) and 14 (471.25 MHz).

> [29384.831876] tuner 1-0061: Standard: 0x0000b000
> [29384.833601] cs5345 0-004c: Input: 1
> [29384.833603] cs5345 0-004c: Volume: 0 dB
> [29384.833604] cx18-0: Video Input: Tuner 1
> [29384.833606] cx18-0: Audio Input: Tuner 1
> [29384.833608] cx18-0: GPIO: direction 0x00003001, value 0x00003001
> [29384.833609] cx18-0: Tuner: TV
> [29384.833611] cx18-0: Stream: MPEG-2 DVD-compatible Stream
> [29384.833614] cx18-0: VBI Format: Private packet, IVTV format
> [29384.833617] cx18-0: Video: 720x480, 30 fps
> [29384.833620] cx18-0: Video: MPEG-2, 4x3, Variable Bitrate,
> 2000000, Peak 3500000
> [29384.833623] cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
> [29384.833626] cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 256 kbps,
> Stereo, No Emphasis, No CRC
> [29384.833629] cx18-0: Spatial Filter: Manual, Luma 1D Horizontal,
> Chroma 1D Horizontal, 0
> [29384.833631] cx18-0: Temporal Filter: Manual, 8
> [29384.833634] cx18-0: Median Filter: Off, Luma [0, 255], Chroma
> [0, 255]
> [29384.833636] cx18-0: Status flags: 0x00200001
> [29384.833638] cx18-0: Stream encoder MPEG: status 0x0000, 0% of
> 2048 KiB (64 buffers) in use
> [29384.833641] cx18-0: Stream encoder YUV: status 0x0000, 0% of 2048
> KiB (16 buffers) in use
> [29384.833644] cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015
> KiB (20 buffers) in use
> [29384.833647] cx18-0: Stream encoder PCM audio: status 0x0000, 0%
> of 1024 KiB (256 buffers) in use
> [29384.833649] cx18-0: Read MPEG/VBI: 66054144/0 bytes
> [29384.833651] cx18-0: ================== END STATUS CARD #0
> ==================
>
> The differences I see are:
> - I've got VBI enabled, even though I don't expect CCs at this time.

MythTV always sets it up. I'm not sure if it always turns it on though.
You would have seen another capture stream start (CX18_CAPTURE_START) in
your debug logs, if the VBI stream actually started. We have to set the
VBI parameters when the first stream starts. We can't change VBI
parameters until all analog streams are stopped due to firmware imposed
rules.


> - I'm using DVD compatible and you're using MPEG-PS.
> - I'm using much lower bitrates for video vbr=2 mbps and peak=3.5 mbps,
> these work well with my PVR-150 and keep recordings down to around 1GB/hour.
> - I'm using a higher bitrate for audio 256 kbps vs 224.

These didn't seem to matter in affecting the static I have on channel
32.


> - tuner frequency and standard are different. I'm tuning to channel 29
> on cable. I'm guessing you're tuning to a broadcast channel?

I was tuned to broadcast channel 20 (507.25 MHz) at the time, with which
I have no audio problem. It's close to cable channel 71 (505.25 MHz).

I was set to look for just NTSC-M. You were set to autodetect NTSC-M
NTSC-M as implemented in Japan, or NTSC-M as implemented in Korea. That
shouldn't have affected things, but you can try and set it back to just
looking for NTSC-M with v4l2-ctl, to see if it make a difference.


> Perhaps I should try using your parameters, including disabling VBI,
> still using cable? Broadcast is out of the question for me.

They likely won't matter given my tests with channel 32. You should
confirm though.



> Anyway, I'm now going to hook up the DVD player and see what happens.

For inputs other than the analog RF tuner, I suspect you won't get the
static.

Also for an RF source with only one (e.g a VCR) or only a few weak (e.g.
rabbit ears and a UHF loop or bow) RF channels, I suspect your
HVR-1600's analog tuner won't produce the static.


> One last thing. I had trimmed the dmesg output after "End
> initialization", but I thought you might want to see the debug output
> during the recording, including the firmware loading.

Yes, thank you.


> Actually, there
> were two recordings during this time, a few minutes of a recording on
> channel 7 I interrupted when I stopped and restarted mythbackend, and
> the recording on the problem channel 29. It follows my signature. Hope
> you don't mind another 167 lines!

Meh, no big deal. Although if you can prevent the line wrap next
time....

> Helen
>
> [26052.964096] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> [26052.989319] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-apu.fw
> [26053.009007] cx18-0: info: load segment a00000-a07fff
> [26053.031785] cx18-0: info: load segment ae0000-ae00ff
> [26053.031964] cx18-0: info: load segment b00000-b1a65f
> [26053.107122] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> (141200 bytes)
> [26053.111865] cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0
> (Release 2007/03/12)
> [26053.111867] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> [26053.316027] cx18-0: api: CX18_CPU_DEBUG_PEEK32 cmd 0x20000003
> args 0x00000000
> [26053.316086] cx18-0: api: CX18_APU_START cmd 0x10000001 args
> 0x000000b9 0x00000000
> [26053.317251] cx18-0: api: CX18_APU_RESETAI cmd 0x10000005 args
> [26053.317681] cx18-0: api: CX18_APU_STOP cmd 0x10000002 args
> 0x00000000
> [26053.320796] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-cpu.fw
> [26053.461133] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-apu.fw
> [26053.465489] cx18-0: info: load segment a00000-a07fff
> [26053.488190] cx18-0: info: load segment ae0000-ae00ff
> [26053.488370] cx18-0: info: load segment b00000-b1a65f
> [26053.569182] cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0
> (Release 2007/03/12)
> [26053.772019] cx18-0: api: CX18_CPU_DEBUG_PEEK32 cmd 0x20000003
> args 0x00000000
> [26053.772075] cx18-0: api: CX18_APU_START cmd 0x10000001 args
> 0x000000b9 0x00000000
> [26053.773248] cx18-0: api: CX18_APU_RESETAI cmd 0x10000005 args
> [26053.773678] cx18-0: api: CX18_APU_STOP cmd 0x10000002 args
> 0x00000000
> [26053.773744] cx18 0000:01:09.0: firmware: requesting v4l-cx23418-dig.fw
> [26053.966498] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> [26053.966541] cx18-0: info: Changing input from 1 to 0
> [26053.966543] cx18-0: info: Mute
> [26053.966545] cx18-0 843: info: decoder set video input 7, audio input 8
> [26053.967472] cx18-0 843: info: decoder set video input 7, audio input 8
> [26053.967538] cx18-0: info: Unmute
> [26053.967539] cx18-0: info: Switching standard to 1000.
> [26053.967541] cx18-0 843: info: changing video std to fmt 1
> [26053.967556] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26053.967557] cx18-0 843: info: PLL = 107.999999 MHz
> [26053.967559] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26053.967560] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26053.967562] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26053.967564] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26053.968319] cx18-0: info: Mute
> [26053.968320] cx18-0: info: v4l2 ioctl: set frequency 1076
> [26053.969046] cx18-0: info: Unmute

All normal.


> [26102.188063] cx18-0: info: Input unchanged
> [26102.188068] cx18-0: info: Switching standard to b000.

0x1000 = V4L2_STD_NTSC_M
0xb000 = V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_JP | V4L2_STD_NTSC_M_KR

0xb000 is a wildcard match for any type of NTSC-M system. No big deal.


> [26102.188070] cx18-0 843: info: changing video std to fmt 1
> [26102.188086] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26102.188088] cx18-0 843: info: PLL = 107.999999 MHz
> [26102.188089] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26102.188090] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26102.188092] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26102.188094] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26102.190696] cx18-0: info: Input unchanged
> [26102.191473] cx18-0: info: Mute
> [26102.191476] cx18-0: info: v4l2 ioctl: set frequency 2804
> [26102.192208] cx18-0: info: Unmute
> [26106.048921] cx18-0: info: Input unchanged
> [26106.050874] cx18-0: info: Mute
> [26106.050877] cx18-0: info: v4l2 ioctl: set frequency 2804
> [26106.051608] cx18-0: info: Unmute
> [26106.069672] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
> 0x20020011 args 0xffffffff 0x000000c9

Setting 256 kbps audio layer II rate.

No stream is open yet, so the task handle is 0xffffffff.

> [26106.070328] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
> args 0xffffffff 0x00000000 0x001e8480 0x00004e20 0x00000000

nominal bit rate = 2000000 bps
peak bit rate = 8000000 bps

No stream is open yet, so the task handle is 0xffffffff

> [26106.070426] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
> 0x20020012 args 0xffffffff 0x0000000e

DVD compatible stream

No stream is open yet, so the task handle is 0xffffffff


> [26106.070477] cx18-0: info: disabled insertion of sliced VBI data into
> the MPEG stream

The driver will refuse to stuff custom VBI packets in a DVD stream,
since the driver doesn't know how to do this in software. That prevents
your stream from getting corrupted.

> [26106.070529] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26106.070531] cx18-0 843: info: PLL = 107.999999 MHz
> [26106.070533] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26106.070534] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26106.070536] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26106.070538] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26106.070651] cx18-0: info: disabled insertion of sliced VBI data into
> the MPEG stream
> [26106.070711] cx18-0: info: Start encoder stream encoder MPEG
> [26106.070714] cx18-0: api: CX18_CREATE_TASK cmd 0x40000001 args
> 0x20020000
> [26106.070768] cx18-0: api: CX18_CPU_SET_CHANNEL_TYPE cmd 0x20020001
> args 0x00000000 0x00000001
> [26106.070819] cx18-0: api: CX18_CPU_SET_VER_CROP_LINE cmd 0x2002001b
> args 0x00000000 0x00000000
> [26106.070871] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000003 0x00000001
> [26106.070925] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000008 0x00000000
> [26106.070977] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000004 0x00000001
> [26106.071029] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x0000000c
> [26106.071077] cx18-0: api: CX18_CPU_SET_CAPTURE_LINE_NO cmd
> 0x20020017 args 0x00000000 0x00000138 0x00000139
> [26106.071134] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26106.071135] cx18-0 843: info: PLL = 107.999999 MHz
> [26106.071137] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26106.071138] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26106.071140] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26106.071142] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26106.071237] cx18-0: info: Setup VBI h: 0 lines 120012 bpl 272 fr 1
> b0f0b0f0 a0e0a0e0
> [26106.071240] cx18-0: api: CX18_CPU_SET_RAW_VBI_PARAM cmd 0x20020016
> args 0x00000000 0x00120012 0x00000110 0x00000001 0xb0f0b0f0 0xa0e0a0e0
> [26106.368023] cx18-0: api: CX18_CPU_SET_INDEXTABLE cmd 0x20020010
> args 0x00000000
> [26106.368078] cx18-0: api: CX18_CPU_SET_VIDEO_IN cmd 0x20020004
> args 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
> [26106.368147] cx18-0: api: CX18_CPU_SET_VIDEO_RESOLUTION cmd
> 0x20020006 args 0x00000000 0x000002d0 0x000001e0
> [26106.368210] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
> 0x20020012 args 0x00000000 0x0000000e
> [26106.368265] cx18-0: api: CX18_CPU_SET_ASPECT_RATIO cmd 0x2002001e
> args 0x00000000 0x00000002
> [26106.368317] cx18-0: api: CX18_CPU_SET_GOP_STRUCTURE cmd 0x2002001c
> args 0x00000000 0x0000000f 0x00000003
> [26106.368369] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
> 0x20020011 args 0x00000000 0x000000c9
> [26106.368428] cx18-0: api: CX18_CPU_SET_AUDIO_MUTE cmd 0x20020014
> args 0x00000000 0x00000000
> [26106.368494] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
> args 0x00000000 0x00000000 0x001e8480 0x00004e20 0x00000000
> [26106.370230] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000001 0x00000000 0x00000000
> [26106.370286] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000000 0x00000001 0x00000008
> [26106.370339] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000002 0x00000000 0x00000000
> [26106.370396] cx18-0: api: CX18_CPU_SET_MEDIAN_CORING cmd 0x2002000e
> args 0x00000000 0x00000000 0x000000ff 0x00000000 0x000000ff
> [26106.370457] cx18-0: api: CX18_CPU_SET_SPATIAL_FILTER_TYPE cmd
> 0x2002000c args 0x00000000 0x00000001 0x00000001
> [26106.370513] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000001 0x00000000 0x00000000
> [26106.370566] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000000 0x00000001 0x00000008
> [26106.370620] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000002 0x00000000 0x00000000
> [26106.370674] cx18-0: api: CX18_CPU_SET_SKIP_INPUT_FRAME cmd
> 0x2002001f args 0x00000000 0x00000000
> [26106.370724] cx18-0: api: CX18_CPU_SET_VIDEO_MUTE cmd 0x20020013
> args 0x00000000 0x00808000
> [26106.370774] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000007 0x00000000 0x00000000
> [26106.370832] cx18-0: api: CX18_CPU_DE_SET_MDL_ACK cmd 0x20040002
> args 0x00000000 0x00dc0c40 0x00dc0c48
> [26106.377264] cx18-0: api: CX18_CPU_CAPTURE_START cmd 0x20020002
> args 0x00000000
> [26192.902880] cx18-0: info: close stopping capture
> [26192.902883] cx18-0: info: Stop Capture
> [26192.902886] cx18-0: api: CX18_CPU_CAPTURE_STOP cmd 0x20020003
> args 0x00000000 0x00000001
> [26193.200037] cx18-0: api: CX18_CPU_DE_RELEASE_MDL cmd 0x20040006
> args 0x00000000
> [26193.500037] cx18-0: api: CX18_DESTROY_TASK cmd 0x40000002 args
> 0x00000000

End of first capture.

> [26252.392930] cx18-0: info: Input unchanged
> [26252.394922] cx18-0: info: Mute
> [26252.394926] cx18-0: info: v4l2 ioctl: set frequency 4052
> [26252.395656] cx18-0: info: Unmute
> [26252.413112] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
> args 0xffffffff 0x00000000 0x001e8480 0x0000222e 0x00000000

bit rate = 2000000 bps
Peak bit rate = 3500000 bps

> [26252.413310] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26252.413314] cx18-0 843: info: PLL = 107.999999 MHz
> [26252.413315] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26252.413317] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26252.413318] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26252.413321] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26252.413494] cx18-0: info: Start encoder stream encoder MPEG
> [26252.413497] cx18-0: api: CX18_CREATE_TASK cmd 0x40000001 args
> 0x20020000
> [26252.413549] cx18-0: api: CX18_CPU_SET_CHANNEL_TYPE cmd 0x20020001
> args 0x00000000 0x00000001
> [26252.413600] cx18-0: api: CX18_CPU_SET_VER_CROP_LINE cmd 0x2002001b
> args 0x00000000 0x00000000
> [26252.413652] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000003 0x00000001
> [26252.413709] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000008 0x00000000
> [26252.420032] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000004 0x00000001
> [26252.420094] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x0000000c
> [26252.420147] cx18-0: api: CX18_CPU_SET_CAPTURE_LINE_NO cmd
> 0x20020017 args 0x00000000 0x00000138 0x00000139
> [26252.420209] cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> [26252.420210] cx18-0 843: info: PLL = 107.999999 MHz
> [26252.420212] cx18-0 843: info: PLL/8 = 13.499999 MHz
> [26252.420213] cx18-0 843: info: ADC Sampling freq = 14.317382 MHz
> [26252.420215] cx18-0 843: info: Chroma sub-carrier freq = 3.579545 MHz
> [26252.420217] cx18-0 843: info: hblank 122, hactive 720, vblank 26,
> vactive 481, vblank656 38, src_dec 543, burst 0x5b, luma_lpf 1, uv_lpf
> 1, comb 0x66, sc 0x087c1f
> [26252.420315] cx18-0: info: Setup VBI h: 0 lines 120012 bpl 272 fr 1
> b0f0b0f0 a0e0a0e0
> [26252.420318] cx18-0: api: CX18_CPU_SET_RAW_VBI_PARAM cmd 0x20020016
> args 0x00000000 0x00120012 0x00000110 0x00000001 0xb0f0b0f0 0xa0e0a0e0
> [26252.720014] cx18-0: api: CX18_CPU_SET_INDEXTABLE cmd 0x20020010
> args 0x00000000
> [26252.720077] cx18-0: api: CX18_CPU_SET_VIDEO_IN cmd 0x20020004
> args 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
> [26252.720151] cx18-0: api: CX18_CPU_SET_VIDEO_RESOLUTION cmd
> 0x20020006 args 0x00000000 0x000002d0 0x000001e0
> [26252.720217] cx18-0: api: CX18_CPU_SET_STREAM_OUTPUT_TYPE cmd
> 0x20020012 args 0x00000000 0x0000000e
> [26252.720270] cx18-0: api: CX18_CPU_SET_ASPECT_RATIO cmd 0x2002001e
> args 0x00000000 0x00000002
> [26252.720322] cx18-0: api: CX18_CPU_SET_GOP_STRUCTURE cmd 0x2002001c
> args 0x00000000 0x0000000f 0x00000003
> [26252.720374] cx18-0: api: CX18_CPU_SET_AUDIO_PARAMETERS cmd
> 0x20020011 args 0x00000000 0x000000c9
> [26252.720440] cx18-0: api: CX18_CPU_SET_AUDIO_MUTE cmd 0x20020014
> args 0x00000000 0x00000000
> [26252.720516] cx18-0: api: CX18_CPU_SET_VIDEO_RATE cmd 0x20020005
> args 0x00000000 0x00000000 0x001e8480 0x0000222e 0x00000000
> [26252.720578] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000001 0x00000000 0x00000000
> [26252.720796] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000000 0x00000001 0x00000008
> [26252.720851] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000002 0x00000000 0x00000000
> [26252.720907] cx18-0: api: CX18_CPU_SET_MEDIAN_CORING cmd 0x2002000e
> args 0x00000000 0x00000000 0x000000ff 0x00000000 0x000000ff
> [26252.720968] cx18-0: api: CX18_CPU_SET_SPATIAL_FILTER_TYPE cmd
> 0x2002000c args 0x00000000 0x00000001 0x00000001
> [26252.721024] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000001 0x00000000 0x00000000
> [26252.721078] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000000 0x00000001 0x00000008
> [26252.721132] cx18-0: api: CX18_CPU_SET_FILTER_PARAM cmd 0x20020009
> args 0x00000000 0x00000002 0x00000000 0x00000000
> [26252.721188] cx18-0: api: CX18_CPU_SET_SKIP_INPUT_FRAME cmd
> 0x2002001f args 0x00000000 0x00000000
> [26252.721237] cx18-0: api: CX18_CPU_SET_VIDEO_MUTE cmd 0x20020013
> args 0x00000000 0x00808000
> [26252.721287] cx18-0: api: CX18_CPU_SET_MISC_PARAMETERS cmd
> 0x20020015 args 0x00000000 0x00000007 0x00000000 0x00000000
> [26252.721345] cx18-0: api: CX18_CPU_DE_SET_MDL_ACK cmd 0x20040002
> args 0x00000000 0x00dc0c40 0x00dc0c48
> [26252.725479] cx18-0: api: CX18_CPU_CAPTURE_START cmd 0x20020002
> args 0x00000000
> [26461.273809] cx18-0: info: close stopping capture
> [26461.273812] cx18-0: info: Stop Capture
> [26461.273815] cx18-0: api: CX18_CPU_CAPTURE_STOP cmd 0x20020003
> args 0x00000000 0x00000001
> [26461.572026] cx18-0: api: CX18_CPU_DE_RELEASE_MDL cmd 0x20040006
> args 0x00000000
> [26461.872020] cx18-0: api: CX18_DESTROY_TASK cmd 0x40000002 args
> 0x00000000


End of second capture.

Nothing really exciting or unusual.

Regards,
Andy


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

Hi Andy.

> You can certainly use the v4l2-ctl that came with your distro.

Then that's what I'll do, it includes ivtv-tune, too. I was mostly
concerned about possible incompatibility with the driver, maybe an ioctl
not part of the v4l2 spec.

> I don't think it's a board problem. I think it's an incoming signal
> problem. If your cable signals on some channels are so strong that they
> start overdriving the analog receiver front end (bumping into non-linear
> regions of the amplifiers), then you can get intermodulation products
> which will show up as noise on other channels. The 3rd order
> intermodulation products can be particularly strong at frequencies
> *higher* than the two or more strong channels that caused them.

That's an interesting hypothesis. FWIW, about a year ago, the cable
company upgraded our connection from outside. We're 200 feet from their
box, and I think they replaced an RG-6 cable with RG-7, maybe RG-8 (not
sure if I remember what the guy told me). That goes into the attic,
where it's split to the cable modem and to an inline amplifier. It then
goes into an 8 way splitter. From there it goes to various rooms,
including mine. I'm pretty sure it's RG-6 cable going to a wall mount.
Then a 50 foot RG-6 cable goes to a 4 way splitter to 3 foot RG-6 cables
to the TV, PVR-150 in old computer, and the HVR-1600 NTSC & ATSC/QAM
connectors. I first noticed the static when I had a extra split, 8
way to 2 way to a cheap 4 way. And mythtv was having trouble finding all
my clear QAM channels. I was hoping eliminating the 2 way split and
replacing the cheap 4 way with a better quality one would allow me to
get all my QAM channels and possibly clear up the static. I would have
thought there were lots of places where I was losing signal strength,
but maybe not enough to make the HVR-1600 happy.

Since my PVR-150 doesn't have a problem with static coming off the same
splitter, I'm wondering if maybe the analog components on the HVR-1600
are inferior to the PVR-150. If so, do you have any opinion about what
would be a better dual tuner card? Too bad they're not allowed to sell
analog only cards anymore.

> I think I have detected the symptoms you describe on broadcast channel
> 32 (579.25 MHz) on my setup with my HVR-1600. The static is slight, but
> it is noticable and consistent.

I sure hope it's the same root cause.

> There are relatively few strong over the air station where I am at. It
> shouldn't take me too long to build up a spreadsheet of all the possible
> intermodulation products that pairs of strong stations below channel 32
> could create on channel 32's frequency band.
>
> If I'm right, then attenuationing the strong stations with an external
> attenuatior or filter should make the static go away.

Would such a device be limited to a narrow frequency range? I guess I'm
wondering if it would interfere with my ability to tune clear QAM
channels. Although, since the HVR-1600 has separate inputs, I guess it
doesn't matter.

> Since I can reproduce this, I'll try and debug this without you going
> through too many hoops. Hopefully the symptoms won't go away. Over the
> air propagation can be weather and time of day dependent...

Don't worry about me going through hoops. I see this as an opportunity
to contribute. I wish OTA was an option for me. According to antennaweb,
I would need a large directional antenna to get most of the stations I
want. I would need three to get all the stations I want. I'm ENE of most
Detroit area stations, WNW of two Canadian stations we like, and S of a
Flint station we like.

> This all looks OK, after a cursory glance. You may want to unload
> lirc_i2c while testing, just to eliminate any possible unknown due to
> lirc.. lirc_i2c is going to use the first I2C master of the CX23418 to
> talk to the Z8 IR microcontroller chip. The analog tuner commands are
> sent on the second I2C master of the CX23418 chip.

Done. lirc_dev is still there, hope that's OK.

> I was set to look for just NTSC-M. You were set to autodetect NTSC-M
> NTSC-M as implemented in Japan, or NTSC-M as implemented in Korea. That
> shouldn't have affected things, but you can try and set it back to just
> looking for NTSC-M with v4l2-ctl, to see if it make a difference.

Must be a myth thing. It gives you a choice between NTSC and NTSC-JP, no
mention of Korea. I will try setting it to just NTSC-M.

>> Anyway, I'm now going to hook up the DVD player and see what happens.
>
> For inputs other than the analog RF tuner, I suspect you won't get the
> static.
>
> Also for an RF source with only one (e.g a VCR) or only a few weak (e.g.
> rabbit ears and a UHF loop or bow) RF channels, I suspect your
> HVR-1600's analog tuner won't produce the static.

Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
Would it be a useful data point if I hooked it up to the HVR-1600?

> Meh, no big deal. Although if you can prevent the line wrap next
> time....

I'll try to remember.

> The driver will refuse to stuff custom VBI packets in a DVD stream,
> since the driver doesn't know how to do this in software. That prevents
> your stream from getting corrupted.

Mind if I go off-topic and ask about the status of VBI? The ivtv
driver adds a private data stream containing VBI data to a DVD stream. I
assumed that eventually, the cx18 driver would do the same. If I change
to MPEG-PS, will I get that VBI stream now? If you need a tester for
this feature, I'm very interested!

I did test the S-Video/Line-In inputs. No static. And channel 29 still
has static, despite removing lirc_i2c.

It's getting late and I'm feeling less pressure since it looks like
you've got a plan. I will do more testing with your parameters over the
weekend.

TTYL,
Helen


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

On Fri, 2009-04-17 at 00:36 -0400, faginbagin wrote:

> > I don't think it's a board problem. I think it's an incoming signal
> > problem. If your cable signals on some channels are so strong that they
> > start overdriving the analog receiver front end (bumping into non-linear
> > regions of the amplifiers), then you can get intermodulation products
> > which will show up as noise on other channels. The 3rd order
> > intermodulation products can be particularly strong at frequencies
> > *higher* than the two or more strong channels that caused them.
>
> That's an interesting hypothesis. FWIW, about a year ago, the cable
> company upgraded our connection from outside. We're 200 feet from their
> box, and I think they replaced an RG-6 cable with RG-7, maybe RG-8 (not
> sure if I remember what the guy told me).
> That goes into the attic,
> where it's split to the cable modem and to an inline amplifier. It then
> goes into an 8 way splitter. From there it goes to various rooms,
> including mine. I'm pretty sure it's RG-6 cable going to a wall mount.
> Then a 50 foot RG-6 cable goes to a 4 way splitter to 3 foot RG-6 cables
> to the TV, PVR-150 in old computer, and the HVR-1600 NTSC & ATSC/QAM
> connectors. I first noticed the static when I had a extra split, 8
> way to 2 way to a cheap 4 way. And mythtv was having trouble finding all
> my clear QAM channels. I was hoping eliminating the 2 way split and
> replacing the cheap 4 way with a better quality one would allow me to
> get all my QAM channels and possibly clear up the static.

Please double check the guidelines here:

http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality


An unterminated splitter output can cause reflections that show up as
elevated noise floor.

For the record there are two things that can happen to your signal: you
can lose signal power or you can get additional noise or interference
added. Although the net result may be the same (degraded signal to
noise ratio), the mechanisms, and hence remedies, may be different.


> I would have
> thought there were lots of places where I was losing signal strength,
> but maybe not enough to make the HVR-1600 happy.
>
> Since my PVR-150 doesn't have a problem with static coming off the same
> splitter, I'm wondering if maybe the analog components on the HVR-1600
> are inferior to the PVR-150.

First, I have had a 4 way spliteer where one (and only one) of the
output ports was bad. It was a brand new expensive one too. :(


Second, if my guess about intermodulation products being introduced by
strong incoming signals in the front-end amp is correct, weak signals
are not the problem, strong ones are. The strong signals get clipped
when they overdrive the amp and spectral components end up somewhere
else in the RF spectrum (i.e. on another channel) showing up as noise.

Since BTSC audio is FM, and since you have watchable video so a strong
enough FM audio signal, and since natural FM noise sources are rare, it
would make sense that intermodulation products could create the audio
static.

I can't call the HVR-1600 analog tuner inferior in this case, because it
could be that the tuner's 1st stage amplifier has a higher gain, if the
problem is due to intermodulation products. Or it could be inferior in
that the 3rd order intercept points of the components before the IF
filter are lower than that of the PVR-150's tuner. Without knowing both
tuners and the having the spec for both, it would be hard to tell which
is better under what circumstances.


> If so, do you have any opinion about what
> would be a better dual tuner card? Too bad they're not allowed to sell
> analog only cards anymore.
>
> > I think I have detected the symptoms you describe on broadcast channel
> > 32 (579.25 MHz) on my setup with my HVR-1600. The static is slight, but
> > it is noticable and consistent.
>
> I sure hope it's the same root cause.

Well, my spreadsheet tells me that a 3rd order intermodulation product
of channel 26 (543.25 MHz) and channel 20 (507.25 MHz) located at
2*f1-f2 = 579.25 MHz lands in channel 32. Since Channel 26 and 20 are
strong channels, and will certainly pass right through the UHF
preselector filter into the first amp, I'm not looking any further for
possible intermods - those stations are the ones that matter.

I've got a few tests to run:

1. I tried to use about 100 ft of RG-6 as an in-line attenuator to get
rid of possible intermods. It didn't have a noticeable effect on the
static on channel 32. I don't know how much attenuation I'm getting out
of my length of cable, but maybe not enough.....

2. I'll build a bridged-T in line attenuator sometime later this
weekend, where I can control the attenuation.

3. I'll try and twiddle the audio processing in the cx18 driver to use
the tuner AF out instead of the SIF. If the origin of the static is not
somewhere in the tuner but in the CX23418 digitization and broadcast
dematrix, then static shouldn't persist under this configuration.


You, however, may want to just try bypassing you in line amplifier and
seeing if the static goes away.



> > There are relatively few strong over the air station where I am at. It
> > shouldn't take me too long to build up a spreadsheet of all the possible
> > intermodulation products that pairs of strong stations below channel 32
> > could create on channel 32's frequency band.
> >
> > If I'm right, then attenuationing the strong stations with an external
> > attenuatior or filter should make the static go away.
>
> Would such a device be limited to a narrow frequency range? I guess I'm
> wondering if it would interfere with my ability to tune clear QAM
> channels. Although, since the HVR-1600 has separate inputs, I guess it
> doesn't matter.

A simple attenuator would just be resistive. Bypassing your inline amp
temporarily would have a similar effect.


> > Since I can reproduce this, I'll try and debug this without you going
> > through too many hoops. Hopefully the symptoms won't go away. Over the
> > air propagation can be weather and time of day dependent...
>
> Don't worry about me going through hoops. I see this as an opportunity
> to contribute. I wish OTA was an option for me. According to antennaweb,
> I would need a large directional antenna to get most of the stations I
> want. I would need three to get all the stations I want.

Three antennas combined would hurt signal to noise ratio. You'd get the
signal from one antenna with the noise from 3 antennas. Manmade and
galactic noise dominate at VHF and UHF. With 3 antennas pointed towards
3 cities you'll get more manmade noise and would be more likely to have
a strong galatic noise source in the beam of an antenna (i.e. pointed at
the galactic disk) at any given time of day.


> I'm ENE of most
> Detroit area stations, WNW of two Canadian stations we like, and S of a
> Flint station we like.
>
> > This all looks OK, after a cursory glance. You may want to unload
> > lirc_i2c while testing, just to eliminate any possible unknown due to
> > lirc.. lirc_i2c is going to use the first I2C master of the CX23418 to
> > talk to the Z8 IR microcontroller chip. The analog tuner commands are
> > sent on the second I2C master of the CX23418 chip.
>
> Done. lirc_dev is still there, hope that's OK.

Yeah.


> > I was set to look for just NTSC-M. You were set to autodetect NTSC-M
> > NTSC-M as implemented in Japan, or NTSC-M as implemented in Korea. That
> > shouldn't have affected things, but you can try and set it back to just
> > looking for NTSC-M with v4l2-ctl, to see if it make a difference.
>
> Must be a myth thing. It gives you a choice between NTSC and NTSC-JP, no
> mention of Korea. I will try setting it to just NTSC-M.

v4l2-ctl can do it. I wouldn't worry too much about it though.


> >> Anyway, I'm now going to hook up the DVD player and see what happens.
> >
> > For inputs other than the analog RF tuner, I suspect you won't get the
> > static.
> >
> > Also for an RF source with only one (e.g a VCR) or only a few weak (e.g.
> > rabbit ears and a UHF loop or bow) RF channels, I suspect your
> > HVR-1600's analog tuner won't produce the static.
>
> Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
> Would it be a useful data point if I hooked it up to the HVR-1600?

Well. We know a cable box will only output on channel 3. There is no
chance for intermodulation products and you will also only exercise the
low VHF part of the analog tuner. Your problem on channel 29 manifests
with the UHF part of the tuner with many channels available. If the
static persists with the cable box attached, we'll know it's not a
signal problem if one assumes the analog tuner is not defective.


> > Meh, no big deal. Although if you can prevent the line wrap next
> > time....
>
> I'll try to remember.
>
> > The driver will refuse to stuff custom VBI packets in a DVD stream,
> > since the driver doesn't know how to do this in software. That prevents
> > your stream from getting corrupted.
>
> Mind if I go off-topic and ask about the status of VBI? The ivtv
> driver adds a private data stream containing VBI data to a DVD stream. I
> assumed that eventually, the cx18 driver would do the same. If I change
> to MPEG-PS, will I get that VBI stream now? If you need a tester for
> this feature, I'm very interested!

It works, both sliced and raw. I've got to make improvements for
non-NTSC standards though.

The interlock on insertion of private packets only in the PS is strictly
a cx18 driver software thing.

I know the insertion will corrupt the MPEG TS and would likely not do
well with the MPEG-1 streams. So I put in an interlock to only let it
happen with the PS. If there are stream types where you know from
experience ivtv wouldn't corrupt the stream, let me know and I'll add it
back for cx18.

Here's what I think about enabling private packet insertion without in
depth analysis of anything other than the PS and TS:

OK 0: MPEG-2 Program Stream
No! 1: MPEG-2 Transport Stream
No? 2: MPEG-1 System Stream
??? 3: MPEG-2 DVD-compatible Stream
No? 4: MPEG-1 VCD-compatible Stream
??? 5: MPEG-2 SVCD-compatible Stream



> I did test the S-Video/Line-In inputs. No static. And channel 29 still
> has static, despite removing lirc_i2c.

Good to know baseband audio isn't having problems.

Regards,
Andy

> It's getting late and I'm feeling less pressure since it looks like
> you've got a plan. I will do more testing with your parameters over the
> weekend.
>
> TTYL,
> Helen



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

Hi Andy,

First, I thought you might be interested in some testing I've done. I
configured my card to match yours, i.e. standard, bit rates, stream
type. And I still had static on channel 29. Then I ran through all the
cable channels and tried to quantify the levels of static I heard on
each station. It's subjective and I want to repeat it, and spend a
little more time on each channel, because sometimes the longer I stay
with a channel, there's a chance the static will clear up to some
degree. Anyway, here are my notes from my first pass:

No sound on 18, 41
Static not noticeable on 2, 3, 5, 16, 17, 20, 21, 54, 56, 59, 60, 61,
62, 63, 64, 65, 66, 67, 68, 69, 70, 81, 82, 83, 84
Not noticeable on 22 (although ivtv-tune did not report "Signal detected")
Slight on 23, 25, 56, 57, 87
Some on 4, 7, 8, 10, 11, 13, 14, 15, 24, 26, 27, 33, 34, 41, 43, 46, 47,
49, 51, 52, 53, 55
Annoying on 6, 29, 30, 31, 32, 36, 37, 38, 40, 42, 58
Not noticeable to annoying on 19 changed with image and/or speaker
Really annoying to annoying on 12, 28 changed with image
No sound to really annoying to annoying on 35
White noise & video on 39, 71-80, 85, 86, 88-116, 118-125, same on TV
(no signal detected by ivtv-tune)
I should get 39 (HSN), 85 (JWLTV), 95 (TBN), 107 (GEMSTV) but not the others
No sound to really annoying on 44
No sound to annoying on 45
Really annoying to annoying on 48
Really annoying to some on 50
No sound on 117 (test pattern)

Hope they make sense. If it will help, I'll put them in a spreadsheet.
Maybe a subjective scale from 0-4? Here are my definitions:

0, Not noticeable: I can't hear static at normal volume
1, Slight: I might not notice it if I weren't listening for it.
2, Some: I notice it, but it's lower than the other sounds.
3, Annoying: About the same volume as other sounds.
4, Really annoying: louder than the other sounds.

> Please double check the guidelines here:
>
> http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality

Will do.

> An unterminated splitter output can cause reflections that show up as
> elevated noise floor.

That is a possibility. I don't think we have TVs hooked up to all the
outputs from the 8 way splitter, although I'm 99% sure they all go to
one room or another.

> First, I have had a 4 way spliteer where one (and only one) of the
> output ports was bad. It was a brand new expensive one too. :(

That's why I swapped connections between my two boards. It didn't
matter. The PVR-150 produced good recordings using what had been the
HVR-1600 connection, and the HVR-1600 still produced static on what had
been the PVR-150 connection.

> You, however, may want to just try bypassing you in line amplifier and
> seeing if the static goes away.

I can probably do this as a test, move the computer to the office and
use the cable modem's unamplified connection. If it works, I'll have to
go into the attic to effect a more permanent solution. Not something I
look forward to, it's got this fluffy insulation that gets all over the
place.

>> Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
>> Would it be a useful data point if I hooked it up to the HVR-1600?
>
> Well. We know a cable box will only output on channel 3. There is no
> chance for intermodulation products and you will also only exercise the
> low VHF part of the analog tuner. Your problem on channel 29 manifests
> with the UHF part of the tuner with many channels available. If the
> static persists with the cable box attached, we'll know it's not a
> signal problem if one assumes the analog tuner is not defective.

So it wouldn't be a waste of time, right? I'm afraid I'm not an EE
although I do have an engineering degree. I sort of get the gist of what
you're saying, but I don't really understand.

I'll probably try this first, since it's easier than moving the computer
around.

> It works, both sliced and raw. I've got to make improvements for
> non-NTSC standards though.

I've tried to figure out the difference between sliced & raw. I searched
a while back, but never found a good explanation. I think I understand
what sliced is. It's what MythTV uses. FWIW, I've written a little
program that extracts the data and passes it off to libzvbi, used by xawtv.

> The interlock on insertion of private packets only in the PS is strictly
> a cx18 driver software thing.
>
> I know the insertion will corrupt the MPEG TS and would likely not do
> well with the MPEG-1 streams. So I put in an interlock to only let it
> happen with the PS. If there are stream types where you know from
> experience ivtv wouldn't corrupt the stream, let me know and I'll add it
> back for cx18.
>
> Here's what I think about enabling private packet insertion without in
> depth analysis of anything other than the PS and TS:
>
> OK 0: MPEG-2 Program Stream
> No! 1: MPEG-2 Transport Stream
> No? 2: MPEG-1 System Stream
> ??? 3: MPEG-2 DVD-compatible Stream
> No? 4: MPEG-1 VCD-compatible Stream
> ??? 5: MPEG-2 SVCD-compatible Stream

Well, I can confirm that the IVTV driver does add the VBI private
packets to the DVD compatible stream and that MythTV will display the
CCs. I haven't used the MPEG-1 stream types, so can't comment.

One way to decide might be how badly it might break applications like
mplayer, xine, myth, dvdauthor or ccextractor. For example, it should be
possible to author a DVD using DVD compatible streams. However, in
practice, dvdauthor, in particular, requires front end applications to
separate the video and audio streams, then put them back together using
mplex (this is something that mytharchive does). I came across someone
who had patched dvdauthor to avoid this CPU and disk intensive step. One
of these days, I was going to check it out. If the patch works with DVD
streams that have no private VBI streams, but does not work with those
DVD streams that have VBI streams, then either that fact should be
documented, so people can make intelligent decisions about configuring
apps like myth, deciding which is more important, the time it takes to
burn a DVD or capturing CCs or Teletext.

Burning DVDs with CCs is a feature near and dear to my heart. I think
the best solution would be if the Hauppauge hardware encoders embedded
CCs in the video stream according to the EIA-608 standard. But they
don't. I believe Panasonic DVD recording appliances do. If I play back a
DVD burned by a Panasonic on another manufacturer's player, I will get
CCs. So they both must implement a common standard like EIA-608.
Panasonics also produce better video quality with better compression
than the PVR-150. But they're appliances which are a lot less flexible
than a computer.

OK, I'm rambling, but maybe it will fuel more dialog on the topic?

Helen

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

On Sat, 2009-04-18 at 02:10 -0400, faginbagin wrote:
> Hi Andy,
>
> First, I thought you might be interested in some testing I've done. I
> configured my card to match yours, i.e. standard, bit rates, stream
> type. And I still had static on channel 29. Then I ran through all the
> cable channels and tried to quantify the levels of static I heard on
> each station. It's subjective and I want to repeat it, and spend a
> little more time on each channel, because sometimes the longer I stay
> with a channel, there's a chance the static will clear up to some
> degree. Anyway, here are my notes from my first pass:
>
> No sound on 18, 41
> Static not noticeable on 2, 3, 5, 16, 17, 20, 21, 54, 56, 59, 60, 61,
> 62, 63, 64, 65, 66, 67, 68, 69, 70, 81, 82, 83, 84
> Not noticeable on 22 (although ivtv-tune did not report "Signal detected")

Channel 22 is at 169.25 MHz which is the last channel freq at the high
end of the Low-VHF preselector filter in the tuner. It might be getting
knocked down by this preselector filter a little, compared to other
cable channels in the the Low-VHF range (2-6, 95-99, and 14-21).


> Slight on 23, 25, 56, 57, 87
> Some on 4, 7, 8, 10, 11, 13, 14, 15, 24, 26, 27, 33, 34, 41, 43, 46, 47,
> 49, 51, 52, 53, 55
> Annoying on 6, 29, 30, 31, 32, 36, 37, 38, 40, 42, 58
> Not noticeable to annoying on 19 changed with image and/or speaker
> Really annoying to annoying on 12, 28 changed with image
> No sound to really annoying to annoying on 35
> White noise & video on 39, 71-80, 85, 86, 88-116, 118-125, same on TV
> (no signal detected by ivtv-tune)

What do you mean here? Sound is "white noise" but the video is
viewable? Is the video clear or very snowy?

Also, a separate TV set is exhibiting the exact same symptoms?


> I should get 39 (HSN), 85 (JWLTV), 95 (TBN), 107 (GEMSTV) but not the others
> No sound to really annoying on 44
> No sound to annoying on 45
> Really annoying to annoying on 48
> Really annoying to some on 50
> No sound on 117 (test pattern)
>
> Hope they make sense. If it will help, I'll put them in a spreadsheet.
> Maybe a subjective scale from 0-4? Here are my definitions:
>
> 0, Not noticeable: I can't hear static at normal volume
> 1, Slight: I might not notice it if I weren't listening for it.
> 2, Some: I notice it, but it's lower than the other sounds.
> 3, Annoying: About the same volume as other sounds.
> 4, Really annoying: louder than the other sounds.

Just to confirm, most of your observations are with the HVR-1600 and not
on the PVR-150 or another TV (except where noted)?


> > An unterminated splitter output can cause reflections that show up as
> > elevated noise floor.
>
> That is a possibility. I don't think we have TVs hooked up to all the
> outputs from the 8 way splitter, although I'm 99% sure they all go to
> one room or another.

It's a good thing to do. It will improve signal to noise ratio. It
likely won't fix your static problem, but if you had any ghosting (a
faint shifted copy of the same channel on the video) it should help.


> > You, however, may want to just try bypassing you in line amplifier and
> > seeing if the static goes away.
>
> I can probably do this as a test, move the computer to the office and
> use the cable modem's unamplified connection. If it works, I'll have to
> go into the attic to effect a more permanent solution. Not something I
> look forward to, it's got this fluffy insulation that gets all over the
> place.

OK. But you're also taking a number of slitters (and hance loss) out of
the test as well. Each equal 2 way split is > 3dB of loss. Each equal
4 way split is > 6 dB of loss. Each equal 8 way split is > 9 dB of
loss. Smaller in line amplifiers are ~ 10 dB of gain. The net effect
of moving to that cable modem drop could be a gain of a few dB and not a
loss. Just let me know how the static sounds.


I have that fluffy (cellulose?) insulation as well. Good stuff, but you
never want to open the attic - the stuff goes everywhere.


> >> Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
> >> Would it be a useful data point if I hooked it up to the HVR-1600?
> >
> > Well. We know a cable box will only output on channel 3. There is no
> > chance for intermodulation products and you will also only exercise the
> > low VHF part of the analog tuner. Your problem on channel 29 manifests
> > with the UHF part of the tuner with many channels available. If the
> > static persists with the cable box attached, we'll know it's not a
> > signal problem if one assumes the analog tuner is not defective.
>
> So it wouldn't be a waste of time, right?

If the static persists with just a cable box that outputs on channel 3,
the problem is likely a problem in setting up the front end digitzer in
the CX23418 or a defective analog tuner on the HVR-1600.


> I'll probably try this first, since it's easier than moving the computer
> around.


As another test, you may also want to try this with v4l2-dbg with a
staticy sounding station tuned. It will switch the CX23418 to use the
mono audio out directly from the analog tuner through the CS5345 audio
chip, much like the audio line-in for Svideo or compsitie video-in. If
the static goes away, I'll know it's a CX23418 digitizer front-end
problem:

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 325h (805d 00000011 00100101b)

# v4l2-dbg -c host0 -s 0x2c72014 0xb05
Register 0x02c72014 set to 0xb05

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 305h (773d 00000011 00000101b)


Listen for a difference...

Then change it back:


# v4l2-dbg -c host0 -s 0x2c72014 0xb25
Register 0x02c72014 set to 0xb25

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 325h (805d 00000011 00100101b)

These commands use the syntax of the newest v4l2-dbg utility. If you
are using the older one, the command line args are slightly different.
You must have root privleges to use v4l2-dbg.

FYI, This sequence didn't make static go away for me on channel 32.

Regards,
Andy


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

Hi Andy,

Returning to the original thread...

Andy Walls wrote:
> On Sat, 2009-04-18 at 02:10 -0400, faginbagin wrote:
>> Hi Andy,
>>
>> First, I thought you might be interested in some testing I've done. I
>> configured my card to match yours, i.e. standard, bit rates, stream
>> type. And I still had static on channel 29. Then I ran through all the
>> cable channels and tried to quantify the levels of static I heard on
>> each station. It's subjective and I want to repeat it, and spend a
>> little more time on each channel, because sometimes the longer I stay
>> with a channel, there's a chance the static will clear up to some
>> degree. Anyway, here are my notes from my first pass:
>>
>> No sound on 18, 41
>> Static not noticeable on 2, 3, 5, 16, 17, 20, 21, 54, 56, 59, 60, 61,
>> 62, 63, 64, 65, 66, 67, 68, 69, 70, 81, 82, 83, 84
>> Not noticeable on 22 (although ivtv-tune did not report "Signal detected")
>
> Channel 22 is at 169.25 MHz which is the last channel freq at the high
> end of the Low-VHF preselector filter in the tuner. It might be getting
> knocked down by this preselector filter a little, compared to other
> cable channels in the the Low-VHF range (2-6, 95-99, and 14-21).
>
>
>> Slight on 23, 25, 56, 57, 87
>> Some on 4, 7, 8, 10, 11, 13, 14, 15, 24, 26, 27, 33, 34, 41, 43, 46, 47,
>> 49, 51, 52, 53, 55
>> Annoying on 6, 29, 30, 31, 32, 36, 37, 38, 40, 42, 58
>> Not noticeable to annoying on 19 changed with image and/or speaker
>> Really annoying to annoying on 12, 28 changed with image
>> No sound to really annoying to annoying on 35
>> White noise & video on 39, 71-80, 85, 86, 88-116, 118-125, same on TV
>> (no signal detected by ivtv-tune)
>
> What do you mean here? Sound is "white noise" but the video is
> viewable? Is the video clear or very snowy?

Both sound and video were "white noise"

> Also, a separate TV set is exhibiting the exact same symptoms?

Yes. IOW, these are channels that my cable company doesn't provide at my
level of service, although I think I should be getting a couple of these
channels, but maybe I'm wrong. I don't care about them, they're shopping
channels, so it's not worth pursuing.
>
>> I should get 39 (HSN), 85 (JWLTV), 95 (TBN), 107 (GEMSTV) but not the others
>> No sound to really annoying on 44
>> No sound to annoying on 45
>> Really annoying to annoying on 48
>> Really annoying to some on 50
>> No sound on 117 (test pattern)
>>
>> Hope they make sense. If it will help, I'll put them in a spreadsheet.
>> Maybe a subjective scale from 0-4? Here are my definitions:
>>
>> 0, Not noticeable: I can't hear static at normal volume
>> 1, Slight: I might not notice it if I weren't listening for it.
>> 2, Some: I notice it, but it's lower than the other sounds.
>> 3, Annoying: About the same volume as other sounds.
>> 4, Really annoying: louder than the other sounds.
>
> Just to confirm, most of your observations are with the HVR-1600 and not
> on the PVR-150 or another TV (except where noted)?

Yes, only the HVR-1600 is exhibiting these symptoms. I haven't gone
through the same process on the PVR-150, but then again, I'm not having
a problem with static on the channels I normally record. But, if it
helps diagnose what's going on, I can.

>>> An unterminated splitter output can cause reflections that show up as
>>> elevated noise floor.
>> That is a possibility. I don't think we have TVs hooked up to all the
>> outputs from the 8 way splitter, although I'm 99% sure they all go to
>> one room or another.
>
> It's a good thing to do. It will improve signal to noise ratio. It
> likely won't fix your static problem, but if you had any ghosting (a
> faint shifted copy of the same channel on the video) it should help.

We do have 7 TVs connected, so there's can only be one unterminated
connection off the 8 way splitter. But I need to double check, I think I
might have put one of those little terminal caps on the one unused wall
jack.

>>> You, however, may want to just try bypassing you in line amplifier and
>>> seeing if the static goes away.
>> I can probably do this as a test, move the computer to the office and
>> use the cable modem's unamplified connection. If it works, I'll have to
>> go into the attic to effect a more permanent solution. Not something I
>> look forward to, it's got this fluffy insulation that gets all over the
>> place.
>
> OK. But you're also taking a number of slitters (and hance loss) out of
> the test as well. Each equal 2 way split is > 3dB of loss. Each equal
> 4 way split is > 6 dB of loss. Each equal 8 way split is > 9 dB of
> loss. Smaller in line amplifiers are ~ 10 dB of gain. The net effect
> of moving to that cable modem drop could be a gain of a few dB and not a
> loss. Just let me know how the static sounds.

I did this test. The results were disappointing. Using the same
terminology as my previous test:

not noticeable 2, 5, 15, 16, 17, 19. 20, 21, 22, 56, 57, 60, 61, 63, 65,
66, 67, 68, 70, 81, 82, 83, 84, 87
slight 6, 9, 10, 23, 24, 58, 59, 62, 64, 69
some 7. 11, 12, 13, 36, 40, 43, 44, 50, 52
annoying 3, 4, 8, 26, 28, 29, 30, 31, 33, 34, 37, 38, 42, 45, 46, 47, 49, 51
really annoying 27, 32, 34, 41, 48, 53, 54, 55

14 started not noticeable but some static came in & out
18 no sound, but sound on TV
25 no sound for a few seconds, then some static
31 had whiny whistle during moment of silence
39, 71-80, 85-86, 96-116, 118-125 white noise (no signal detected) on
TV, too (both video and audio - snowy picture & pure static)
59 no signal detected although static was only slight
95 mostly white noise, really weak video/audio signal
117 test pattern, no audio with slight static

> I have that fluffy (cellulose?) insulation as well. Good stuff, but you
> never want to open the attic - the stuff goes everywhere.

Yep, plus my access panel is in a walk-in closet and I have to put
sheets up to protect the clothes.

>>>> Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
>>>> Would it be a useful data point if I hooked it up to the HVR-1600?
>>> Well. We know a cable box will only output on channel 3. There is no
>>> chance for intermodulation products and you will also only exercise the
>>> low VHF part of the analog tuner. Your problem on channel 29 manifests
>>> with the UHF part of the tuner with many channels available. If the
>>> static persists with the cable box attached, we'll know it's not a
>>> signal problem if one assumes the analog tuner is not defective.
>> So it wouldn't be a waste of time, right?
>
> If the static persists with just a cable box that outputs on channel 3,
> the problem is likely a problem in setting up the front end digitzer in
> the CX23418 or a defective analog tuner on the HVR-1600.

I also did this test, using the cable modem connection, i.e. avoiding
the in-line amplifier & 8 way splitter. What I found was when I changed
channels on the STB, roughly half the time I got either annoying static
or no sound. No sound was more common. It happened across the channel
spectrum. I found that if I waited as long as a minute, more often than
not, the sound would return, usually with some static, and then clear.
And if it started out with static, it would clear after a few seconds.
If the sound did not return, I could clear it, either by switching
channels on the STB or using ivtv-tune to 4 and then back to 3. I'm
really curious to know what you think this means. Could it be evidence
of a defective card, or something else?

> As another test, you may also want to try this with v4l2-dbg with a
> staticy sounding station tuned. It will switch the CX23418 to use the
> mono audio out directly from the analog tuner through the CS5345 audio
> chip, much like the audio line-in for Svideo or compsitie video-in. If
> the static goes away, I'll know it's a CX23418 digitizer front-end
> problem:
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 325h (805d 00000011 00100101b)
>
> # v4l2-dbg -c host0 -s 0x2c72014 0xb05
> Register 0x02c72014 set to 0xb05
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 305h (773d 00000011 00000101b)
>
>
> Listen for a difference...
>
> Then change it back:
>
>
> # v4l2-dbg -c host0 -s 0x2c72014 0xb25
> Register 0x02c72014 set to 0xb25
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 325h (805d 00000011 00100101b)
>
> These commands use the syntax of the newest v4l2-dbg utility. If you
> are using the older one, the command line args are slightly different.
> You must have root privleges to use v4l2-dbg.
>
> FYI, This sequence didn't make static go away for me on channel 32.

I will try this, hopefully later tonight. Real life is beckoning.

As I mentioned in my reply to the VBI thread, my priority is getting my
new machine working. I have promised my sister my old machine, but have
been putting her off, in case I need it to troubleshoot the static
issue. If using mono audio eliminates the static, then that is something
I can live with, IF mythtv lets me do that. If not, I need another plan.

Unless you tell me it's a waste of time, I'm thinking what I should do
is use that old machine to do a more robust check out of my HVR-1600,
namely:

- See if I have the same problems using Hauppauge's WinTV application
under WinXP. I can't do that with the new computer, because it doesn't
have WinXP and I don't see why I should pay M$ for a license I shouldn't
need.

- If WinTV has the same problem, maybe exchange the card and see if
another one works. The one I have is a model 1199, the store also has
model 1178s, which are functionally equivalent. I think the 1178s are
older than the 1199s, but the odd thing is the store is charging $10
more for them.

- If WinTV doesn't have the same problem, then install a newer kernel on
this box, probably the same as is on the new computer. The old computer
has 2.6.24 (ubuntu hardy 8.04). Then compile & install the same cx18
drivers I've got on the new computer. I'm assuming the new drivers will
need, or at least behave better, with a 2.6.28 kernel. And then repeat
the same mplayer/ivtv-tune test.

- If this configuration allows me to get static free recordings on the
old computer, then that suggests something about the new mobo is the
problem. Maybe the kernel needs more time to catch up with my new mobo
and chipset (ASUS m3n78 PRO with Nvidia 8200 chipset). FWIW, I've
already had an inkling that's the case with USB. I tried to set up a
wireless USB adapter without success. Linux thinks it's operating at USB
1.1 speeds, although the same device works at 2.0 speeds on my old
computer. I worked around this by running ethernet cable into the room,
tricky but doable.

Does my plan sound reasonable? One implication is that I would be giving
my sister the old computer with the HVR-1600, which means that, as of
next weekend, I won't be able to help test the cx18 drivers. But if my
mobo and linux kernel support for it are the root cause of my problems,
then maybe I don't really have the piece parts to make a useful
contribution to development of the cx18 drivers.

Regards,
Helen

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

Hi Andy,

I tried to do the following test.

> As another test, you may also want to try this with v4l2-dbg with a
> staticy sounding station tuned. It will switch the CX23418 to use the
> mono audio out directly from the analog tuner through the CS5345 audio
> chip, much like the audio line-in for Svideo or compsitie video-in. If
> the static goes away, I'll know it's a CX23418 digitizer front-end
> problem:
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 325h (805d 00000011 00100101b)

But the above get register command failed with:
ioctl: VIDIOC_DBG_G_REGISTER
ioctl: VIDIOC_DBG_G_REGISTER failed for 0x2c72014

And dmesg didn't show anything.

> # v4l2-dbg -c host0 -s 0x2c72014 0xb05
> Register 0x02c72014 set to 0xb05

And even though I couldn't get the current register value, I still tried
the set. It also failed with:
Failed to set register 0x02c72014 value 0xb05

I was root, and I was using the newest utility I compiled. Also tried the
one installed with the ivtv-utils package and got a usage message. So I
assume I haven't changed the tuner to use mono audio out. I did try
playing a couple of "really annoying" channels. Two out of three were
still really annoying (27 & 41), one (34) had improved to "slight".
FWIW, here's the output from v4l2-ctl --log-status while 41 was tuned in
and mplayer was going:

Status Log:

[135949.888147] cx18-0: ================= START STATUS CARD #0 =================
[135949.888151] cx18-0: Version: 1.1.0 Card: Hauppauge HVR-1600
[135949.925592] tveeprom 0-0050: Hauppauge model 74041, rev C6B2, serial# 5405623
[135949.925594] tveeprom 0-0050: MAC address is 00-0D-FE-52-7B-B7
[135949.925596] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
[135949.925598] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
[135949.925600] tveeprom 0-0050: audio processor is CX23418 (idx 38)
[135949.925602] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
[135949.925603] tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter
[135949.925609] cx18-0 843: Video signal: present
[135949.925610] cx18-0 843: Detected format: NTSC-M
[135949.925612] cx18-0 843: Specified standard: NTSC-M
[135949.925613] cx18-0 843: Specified video input: Composite 7
[135949.925614] cx18-0 843: Specified audioclock freq: 48000 Hz
[135949.925624] cx18-0 843: Detected audio mode: stereo
[135949.925625] cx18-0 843: Detected audio standard: BTSC
[135949.925627] cx18-0 843: Audio muted: no
[135949.925628] cx18-0 843: Audio microcontroller: running
[135949.925629] cx18-0 843: Configured audio standard: automatic detection
[135949.925631] cx18-0 843: Configured audio system: BTSC
[135949.925633] cx18-0 843: Specified audio input: Tuner (In8)
[135949.925634] cx18-0 843: Preferred audio mode: stereo
[135949.927610] cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
[135949.927613] tuner 1-0061: Tuner mode: analog TV
[135949.927615] tuner 1-0061: Frequency: 325.25 MHz
[135949.927616] tuner 1-0061: Standard: 0x00001000
[135949.929842] cs5345 0-004c: Input: 1
[135949.929844] cs5345 0-004c: Volume: 0 dB
[135949.929845] cx18-0: Video Input: Tuner 1
[135949.929847] cx18-0: Audio Input: Tuner 1
[135949.929848] cx18-0: GPIO: direction 0x00003001, value 0x00003001
[135949.929849] cx18-0: Tuner: TV
[135949.929851] cx18-0: Stream: MPEG-2 Program Stream
[135949.929853] cx18-0: VBI Format: No VBI
[135949.929855] cx18-0: Video: 720x480, 30 fps
[135949.929857] cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 6000000, Peak 8000000
[135949.929859] cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
[135949.929861] cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
[135949.929864] cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
[135949.929866] cx18-0: Temporal Filter: Manual, 8
[135949.929867] cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
[135949.929869] cx18-0: Status flags: 0x00200001
[135949.929871] cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use
[135949.929873] cx18-0: Stream encoder YUV: status 0x0000, 0% of 2048 KiB (16 buffers) in use
[135949.929875] cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20 buffers) in use
[135949.929877] cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256 buffers) in use
[135949.929879] cx18-0: Read MPEG/VBI: 24463360/0 bytes
[135949.929881] cx18-0: ================== END STATUS CARD #0 ==================

Any thoughts on why v4l2-dbg can't get/set that register?

FYI, I scanned all the channels on my old computer with the PVR-150.
No problems with static. However, when I got to channel 60, the video lost
color, although the audio was still clean. After rebooting, I continued
scanning. This time, I lost sound on channel 87, which follows some
channels that have white noise (both audio & video, and on any TV). I
tried unloading and reloading ivtv, which didn't restore the audio.
Rebooting did the trick. All but one of the remaining channels have white
noise, but when I did get to that one last channel, a test pattern with no
sound, there was no static.

Regards,
Helen


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

On Tue, 2009-04-21 at 03:00 -0400, faginbagin wrote:
> Hi Andy,
>
> I tried to do the following test.
>
> > As another test, you may also want to try this with v4l2-dbg with a
> > staticy sounding station tuned. It will switch the CX23418 to use the
> > mono audio out directly from the analog tuner through the CS5345 audio
> > chip, much like the audio line-in for Svideo or compsitie video-in. If
> > the static goes away, I'll know it's a CX23418 digitizer front-end
> > problem:
> >
> > # v4l2-dbg -c host0 -g 0x2c72014
> > ioctl: VIDIOC_DBG_G_REGISTER
> > Register 0x02c72014 = 325h (805d 00000011 00100101b)
>
> But the above get register command failed with:
> ioctl: VIDIOC_DBG_G_REGISTER
> ioctl: VIDIOC_DBG_G_REGISTER failed for 0x2c72014
>
> And dmesg didn't show anything.
>
> > # v4l2-dbg -c host0 -s 0x2c72014 0xb05
> > Register 0x02c72014 set to 0xb05
>
> And even though I couldn't get the current register value, I still tried
> the set. It also failed with:
> Failed to set register 0x02c72014 value 0xb05

That can happen when the cx18 and/or videodev module is compiled without
the CONFIG_VIDEO_ADV_DEBUG, or if the default /dev/video device does not
point to a cx18 supported device. It can also happen if you are not
root; changing registers is a privileged operation.

You may want to specify the device with the '-d /dev/videoN' switch.
Here's how you would scan to get some positive feedback that you can at
least query the driver:

# v4l2-dbg -d /dev/video0 -D
Driver info:
Driver name : cx18
Card type : Hauppauge HVR-1600
Bus info : PCI:0000:03:03.0
Driver version: 65792
Capabilities : 0x01030051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
Read/Write

# v4l2-dbg -d /dev/video0 -S
host0: cx23418 revision 0x01010000
host1: cx23418_843 revision 0x00008430
i2c 0x4c: cs5345 revision 0x00000000

(That's an HVR-1600 non-MCE)



> I was root, and I was using the newest utility I compiled. Also tried the
> one installed with the ivtv-utils package and got a usage message. So I
> assume I haven't changed the tuner to use mono audio out.

Correct.


> I did try
> playing a couple of "really annoying" channels. Two out of three were
> still really annoying (27 & 41), one (34) had improved to "slight".
> FWIW, here's the output from v4l2-ctl --log-status while 41 was tuned in
> and mplayer was going:

Well the v4l2-dgb commands had no effect. So I cannot say what caused
the change in quality.



> Any thoughts on why v4l2-dbg can't get/set that register?

See above.


> FYI, I scanned all the channels on my old computer with the PVR-150.
> No problems with static. However, when I got to channel 60, the video lost
> color, although the audio was still clean. After rebooting, I continued
> scanning. This time, I lost sound on channel 87, which follows some
> channels that have white noise (both audio & video, and on any TV). I
> tried unloading and reloading ivtv, which didn't restore the audio.
> Rebooting did the trick. All but one of the remaining channels have white
> noise, but when I did get to that one last channel, a test pattern with no
> sound, there was no static.

I've been investigating with my PVR-150MCE, HVR-1600MCE, and HVR-1600.

1. With the MCE devices where the analog tuners (LG TAPE H001F MK3 in
the PVR-150 MCE, and TCL MFMN05 in the HVR-1600MCE) have a TDA9887
demodulator chip, the static on channel 32 is more noticeable than on
the HVR-1600 with a TCL M2523_5N_E tuner that has a TDA9801 demodulator.

2. Using how noisy the Raw VBI CC lines show up in osc as a qualitative
visual measure of AM Signal to Noise ratio (SNR), Stations with a really
high AM SNR have good sound, as do stations with a really low/poor AM
SNR. The AM SNR on channel 32 seems to be bad, but not terrible
(somewhere in the middle).

3. Experiments with home-made in-line attenuators of 17.5 dB and 23.5 dB
did not improve the sound on channel 32. It only made the video signal
worse.

4. The tuner AF out (vs the SIF out that's normally used) still exhibits
static for the HVR-1600MCE and HVR1600


The only conclusions I can draw are

a. From 1 & 4: my static is likely originating via processes in my
antenna amplifier and/or the analog tuner assembly and not the CX23418
chip's front end.

b. From 3: The source of my static is *not* from intermodulation
products in the analog tuner due to signals that are too strong.


Some speculations I can make are:

c. From 2: The noise on Raw VBI lines, as is viewable with osc, *may* be
an indicator of static appearing in the sound.

d. From 2: The AGC take-over point being set in the demodulator stage of
the analog tuner - where the demod stage takes over gain control from
the 1st mixer/amp - may have something with why very noisy video signals
don't experience audio static, but why mildly noisy signal do experience
audio static.

I need to look into how the analog tuner is being configured and
experiment with some settings. Life has been very busy lately. It may
take me a while to find what's going on.



I also need to look at your other email, and ask some questions about
the cable box behavior.

Regards,
Andy


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

Hi Andy,

I think I have good news regarding the mono out test. And I'd really like to
know if it would be a total waste of my time to test my HVR-1600 in the old
computer using WinXP and Linux with the latest drivers. If not, it's something I
can do before I hand the machine over to my sister this weekend.

> That can happen when the cx18 and/or videodev module is compiled without
> the CONFIG_VIDEO_ADV_DEBUG, or if the default /dev/video device does not
> point to a cx18 supported device. It can also happen if you are not
> root; changing registers is a privileged operation.

CONFIG_VIDEO_ADV_DEBUG was not set. Once I recompiled with it set, here's
the output of the commands.

# v4l2-dbg -d /dev/video0 -D
Driver info:
Driver name : cx18
Card type : Hauppauge HVR-1600
Bus info : PCI:0000:01:09.0
Driver version: 65792
Capabilities : 0x01030051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
Read/Write
Actually this command worked before recompiling with
CONFIG_VIDEO_ADV_DEBUG enabled.

# v4l2-dbg -d /dev/video0 -S
host0: cx23418 revision 0x01010000
host1: cx23418_843 revision 0x00008430
i2c 0x4c: cs5345 revision 0x00000000

Setting to mono:

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 320h (800d 00000011 00100000b)

# v4l2-dbg -c host0 -s 0x2c72014 0xb05
Register 0x02c72014 set to 0xb05
(Although I wonder if the value should have been 0xb00 since the
original register value was 0x320, not 0x325.)

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 305h (773d 00000011 00000101b)

Results:

No noticeable static on any channel my TV can tune! This is great news to
me. It means I might be able to work around the problem, meaning I'll have
a usable myth system and a system that I can also use to contribute some
testing on VBI, for example. You said that if the static went away, you'd
know it's a CX23418 digitizer front-end problem. I'm not quite sure what
that means. Does it mean this particular card might be sub-par and that
perhaps I should exchange it for another? If so, should I try the older
model 1178?

BTW, this test was done going through the inline amp to 8 way to 4 way
splitters. My earlier tests convince me that they are not the root cause
and I don't need to hurry up to the attic to bypass them. I'll still need
the 4 way no matter what.

There was one small issue. The sound was a lot lower with this configuration.
Normally, my TV volume is set to around 10 (maxes out at 63). This level
is appropriate for both the TV tuner and for PVR-150 recordings played
back on my old computer. The new computer seems to have a weaker audio
out, despite me cranking up the mixer volumes to the max. When I use the
new computer to play back recordings made on the old computer with the
PVR-150, I need to set the TV volume to around 15. But I had to crank up
the TV volume even higher (between 22-30 depending on channel)to get a
comparable sound level in this recent test. Not a big deal, just thought
I'd mention it. It is something I'll want to try to adjust so I don't
accidentally blast the TV if I change to the TV tuner without thinking.
One of my dogs is sound sensitive and things like that freak her out.

Restoring stereo:
# v4l2-dbg -c host0 -s 0x2c72014 0xb20
(not 0xb25, to restore original value)
Register 0x02c72014 set to 0xb20

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 320h (800d 00000011 00100000b)

So what are bits 0 and 2 to that register? Should I try setting the value
to 0xb25 and seeing if that allows me to get stereo without static?

>> FYI, I scanned all the channels on my old computer with the PVR-150.
>> No problems with static. However, when I got to channel 60, the video lost
>> color, although the audio was still clean. After rebooting, I continued
>> scanning. This time, I lost sound on channel 87, which follows some
>> channels that have white noise (both audio & video, and on any TV). I
>> tried unloading and reloading ivtv, which didn't restore the audio.
>> Rebooting did the trick. All but one of the remaining channels have white
>> noise, but when I did get to that one last channel, a test pattern with no
>> sound, there was no static.
>
> I've been investigating with my PVR-150MCE, HVR-1600MCE, and HVR-1600.
>
> 1. With the MCE devices where the analog tuners (LG TAPE H001F MK3 in
> the PVR-150 MCE, and TCL MFMN05 in the HVR-1600MCE) have a TDA9887
> demodulator chip, the static on channel 32 is more noticeable than on
> the HVR-1600 with a TCL M2523_5N_E tuner that has a TDA9801 demodulator.
>
> 2. Using how noisy the Raw VBI CC lines show up in osc as a qualitative
> visual measure of AM Signal to Noise ratio (SNR), Stations with a really
> high AM SNR have good sound, as do stations with a really low/poor AM
> SNR. The AM SNR on channel 32 seems to be bad, but not terrible
> (somewhere in the middle).
>
> 3. Experiments with home-made in-line attenuators of 17.5 dB and 23.5 dB
> did not improve the sound on channel 32. It only made the video signal
> worse.
>
> 4. The tuner AF out (vs the SIF out that's normally used) still exhibits
> static for the HVR-1600MCE and HVR1600
>
>
> The only conclusions I can draw are
>
> a. From 1 & 4: my static is likely originating via processes in my
> antenna amplifier and/or the analog tuner assembly and not the CX23418
> chip's front end.
>
> b. From 3: The source of my static is *not* from intermodulation
> products in the analog tuner due to signals that are too strong.
>
>
> Some speculations I can make are:
>
> c. From 2: The noise on Raw VBI lines, as is viewable with osc, *may* be
> an indicator of static appearing in the sound.
>
> d. From 2: The AGC take-over point being set in the demodulator stage of
> the analog tuner - where the demod stage takes over gain control from
> the 1st mixer/amp - may have something with why very noisy video signals
> don't experience audio static, but why mildly noisy signal do experience
> audio static.
>
> I need to look into how the analog tuner is being configured and
> experiment with some settings. Life has been very busy lately. It may
> take me a while to find what's going on.

I understand (at least the bit about life being busy). And let me take this
opportunity to say I really appreciate just how responsive you've been to my
particular issue. One thing I'm unclear about is whether you now think we have
similar root causes. If not, is there a chance that my problem is something that
can, or should, be addressed in software, either kernel or user space. IOW,
might there be an opportunity for me to help test a patch for this issue?

> I also need to look at your other email, and ask some questions about
> the cable box behavior.

Whenever life's not too busy <vbg>. Although I would like to know if it would be
a total waste of my time to test my HVR-1600 in the old computer using WinXP and
Linux with the latest drivers. If not, it's something I can do before I hand the
machine over to my sister.\ this weekend.

Regards,
Helen

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

Hi Andy,

I think I have good news regarding the mono out test. And I'd really like to
know if it would be a total waste of my time to test my HVR-1600 in the old
computer using WinXP and Linux with the latest drivers. If not, it's something I
can do before I hand the machine over to my sister this weekend.

> That can happen when the cx18 and/or videodev module is compiled without
> the CONFIG_VIDEO_ADV_DEBUG, or if the default /dev/video device does not
> point to a cx18 supported device. It can also happen if you are not
> root; changing registers is a privileged operation.

CONFIG_VIDEO_ADV_DEBUG was not set. Once I recompiled with it set, here's
the output of the commands.

# v4l2-dbg -d /dev/video0 -D
Driver info:
Driver name : cx18
Card type : Hauppauge HVR-1600
Bus info : PCI:0000:01:09.0
Driver version: 65792
Capabilities : 0x01030051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
Read/Write
Actually this command worked before recompiling with
CONFIG_VIDEO_ADV_DEBUG enabled.

# v4l2-dbg -d /dev/video0 -S
host0: cx23418 revision 0x01010000
host1: cx23418_843 revision 0x00008430
i2c 0x4c: cs5345 revision 0x00000000

Setting to mono:

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 320h (800d 00000011 00100000b)

# v4l2-dbg -c host0 -s 0x2c72014 0xb05
Register 0x02c72014 set to 0xb05
(Although I wonder if the value should have been 0xb00 since the
original register value was 0x320, not 0x325.)

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 305h (773d 00000011 00000101b)

Results:

No noticeable static on any channel my TV can tune! This is great news to
me. It means I might be able to work around the problem, meaning I'll have
a usable myth system and a system that I can also use to contribute some
testing on VBI, for example. You said that if the static went away, you'd
know it's a CX23418 digitizer front-end problem. I'm not quite sure what
that means. Does it mean this particular card might be sub-par and that
perhaps I should exchange it for another? If so, should I try the older
model 1178?

BTW, this test was done going through the inline amp to 8 way to 4 way
splitters. My earlier tests convince me that they are not the root cause
and I don't need to hurry up to the attic to bypass them. I'll still need
the 4 way no matter what.

There was one small issue. The sound was a lot lower with this configuration.
Normally, my TV volume is set to around 10 (maxes out at 63). This level
is appropriate for both the TV tuner and for PVR-150 recordings played
back on my old computer. The new computer seems to have a weaker audio
out, despite me cranking up the mixer volumes to the max. When I use the
new computer to play back recordings made on the old computer with the
PVR-150, I need to set the TV volume to around 15. But I had to crank up
the TV volume even higher (between 22-30 depending on channel)to get a
comparable sound level in this recent test. Not a big deal, just thought
I'd mention it. It is something I'll want to try to adjust so I don't
accidentally blast the TV if I change to the TV tuner without thinking.
One of my dogs is sound sensitive and things like that freak her out.

Restoring stereo:
# v4l2-dbg -c host0 -s 0x2c72014 0xb20
(not 0xb25, to restore original value)
Register 0x02c72014 set to 0xb20

# v4l2-dbg -c host0 -g 0x2c72014
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72014 = 320h (800d 00000011 00100000b)

So what are bits 0 and 2 to that register? Should I try setting the value
to 0xb25 and seeing if that allows me to get stereo without static?

>> FYI, I scanned all the channels on my old computer with the PVR-150.
>> No problems with static. However, when I got to channel 60, the video lost
>> color, although the audio was still clean. After rebooting, I continued
>> scanning. This time, I lost sound on channel 87, which follows some
>> channels that have white noise (both audio & video, and on any TV). I
>> tried unloading and reloading ivtv, which didn't restore the audio.
>> Rebooting did the trick. All but one of the remaining channels have white
>> noise, but when I did get to that one last channel, a test pattern with no
>> sound, there was no static.
>
> I've been investigating with my PVR-150MCE, HVR-1600MCE, and HVR-1600.
>
> 1. With the MCE devices where the analog tuners (LG TAPE H001F MK3 in
> the PVR-150 MCE, and TCL MFMN05 in the HVR-1600MCE) have a TDA9887
> demodulator chip, the static on channel 32 is more noticeable than on
> the HVR-1600 with a TCL M2523_5N_E tuner that has a TDA9801 demodulator.
>
> 2. Using how noisy the Raw VBI CC lines show up in osc as a qualitative
> visual measure of AM Signal to Noise ratio (SNR), Stations with a really
> high AM SNR have good sound, as do stations with a really low/poor AM
> SNR. The AM SNR on channel 32 seems to be bad, but not terrible
> (somewhere in the middle).
>
> 3. Experiments with home-made in-line attenuators of 17.5 dB and 23.5 dB
> did not improve the sound on channel 32. It only made the video signal
> worse.
>
> 4. The tuner AF out (vs the SIF out that's normally used) still exhibits
> static for the HVR-1600MCE and HVR1600
>
>
> The only conclusions I can draw are
>
> a. From 1 & 4: my static is likely originating via processes in my
> antenna amplifier and/or the analog tuner assembly and not the CX23418
> chip's front end.
>
> b. From 3: The source of my static is *not* from intermodulation
> products in the analog tuner due to signals that are too strong.
>
>
> Some speculations I can make are:
>
> c. From 2: The noise on Raw VBI lines, as is viewable with osc, *may* be
> an indicator of static appearing in the sound.
>
> d. From 2: The AGC take-over point being set in the demodulator stage of
> the analog tuner - where the demod stage takes over gain control from
> the 1st mixer/amp - may have something with why very noisy video signals
> don't experience audio static, but why mildly noisy signal do experience
> audio static.
>
> I need to look into how the analog tuner is being configured and
> experiment with some settings. Life has been very busy lately. It may
> take me a while to find what's going on.

I understand (at least the bit about life being busy). And let me take this
opportunity to say I really appreciate just how responsive you've been to my
particular issue. One thing I'm unclear about is whether you now think we have
similar root causes. If not, is there a chance that my problem is something that
can, or should, be addressed in software, either kernel or user space. IOW,
might there be an opportunity for me to help test a patch for this issue?

> I also need to look at your other email, and ask some questions about
> the cable box behavior.

Whenever life's not too busy <vbg>. Although I would like to know if it would be
a total waste of my time to test my HVR-1600 in the old computer using WinXP and
Linux with the latest drivers. If not, it's something I can do before I hand the
machine over to my sister.\ this weekend.

Regards,
Helen


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

Hi Andy,

>> It means I might be able to work around the problem, meaning I'll have
>> a usable myth system and a system that I can also use to contribute some
>> testing on VBI, for example. You said that if the static went away, you'd
>> know it's a CX23418 digitizer front-end problem.
>
> Yes. You should test the patches at
>
> http://linuxtv.org/hg/~awalls/cx18-init-debug
>
> I had these patches in place for symptoms of "no audio". I didn't occur
> to me that they might help you, until you confired tuner baseband audio
> out was static free.

I will test the patches, but it will have to wait, probably sometime
next week. I have started down the WinXP track. It's taking longer than
expected because I ended up doing a clean reinstall of WinXP. Before
doing that, WinXP was acting flaky. But a clean reinstall also means I
blew away all my Linux partitions. Oh well. I had been thinking the
first disk could use repartitioning, so now's as good a time as any.

>> I'm not quite sure what
>> that means. Does it mean this particular card might be sub-par and that
>> perhaps I should exchange it for another? If so, should I try the older
>> model 1178?
>
> There's a remote chance. If you test the card in a Windows machine and
> audio works fine, it is not a bad card.

I hope to confirm that in the next couple of days.

>> BTW, this test was done going through the inline amp to 8 way to 4 way
>> splitters. My earlier tests convince me that they are not the root cause
>> and I don't need to hurry up to the attic to bypass them. I'll still need
>> the 4 way no matter what.
>
> Agree. This is not an input signal problem.

I'm relieved you agree.

>> One thing I'm unclear about is whether you now think we have
>> similar root causes.
>
> No, we don't. My problem may have a root cause in analog tuner
> configuration. I'll figure it out when it really bugs me, but I rarely
> watch channel 32.
>
>> If not, is there a chance that my problem is something that
>> can, or should, be addressed in software, either kernel or user space. IOW,
>> might there be an opportunity for me to help test a patch for this issue?
>
> Yes. I have high confidence that we should be able to fix your problem
> with software.

I hope that by fixing my problem, it benefits others.

I'll post when I have news about WinXP behavior.

Regards,
Helen


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

On Tue, 2009-04-21 at 17:00 -0400, faginbagin wrote:
> Hi Andy,
>
> I think I have good news regarding the mono out test. And I'd really like to
> know if it would be a total waste of my time to test my HVR-1600 in the old
> computer using WinXP and Linux with the latest drivers. If not, it's something I
> can do before I hand the machine over to my sister this weekend.
>

> Setting to mono:
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 320h (800d 00000011 00100000b)
>
> # v4l2-dbg -c host0 -s 0x2c72014 0xb05
> Register 0x02c72014 set to 0xb05
> (Although I wonder if the value should have been 0xb00 since the
> original register value was 0x320, not 0x325.)
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 305h (773d 00000011 00000101b)
>
> Results:
>
> No noticeable static on any channel my TV can tune! This is great news to
> me.

Good.

> It means I might be able to work around the problem, meaning I'll have
> a usable myth system and a system that I can also use to contribute some
> testing on VBI, for example. You said that if the static went away, you'd
> know it's a CX23418 digitizer front-end problem.

Yes. You should test the patches at

http://linuxtv.org/hg/~awalls/cx18-init-debug

I had these patches in place for symptoms of "no audio". I didn't occur
to me that they might help you, until you confired tuner baseband audio
out was static free.


> I'm not quite sure what
> that means. Does it mean this particular card might be sub-par and that
> perhaps I should exchange it for another? If so, should I try the older
> model 1178?

There's a remote chance. If you test the card in a Windows machine and
audio works fine, it is not a bad card.

More likely it's the Audio Standard autodetection microcontroller
firmware that isn't getting uploaded properly. Testing with the
cx18-init-debug repo will eliminate that possibly as it does a complete
readback of the firmware after it's uploaded and will gripe if it's
wrong.

It could also be that the the Automatic Gain Control for SIF audio in
the CX23418 front end is being driven by the video signal level instead
of the SIF signal level. I'll have to check to make sure the driver's
doing the right thing there.



>
> BTW, this test was done going through the inline amp to 8 way to 4 way
> splitters. My earlier tests convince me that they are not the root cause
> and I don't need to hurry up to the attic to bypass them. I'll still need
> the 4 way no matter what.

Agree. This is not an input signal problem.


> There was one small issue. The sound was a lot lower with this configuration.

Yes. I had you use a baseband analog audio output that comes straight
out of the tuner, to a CS5345 digitizer/mux chip, to the first I2S
(serial digital audio) port on the CX23418.

The CS5345 has a volume control that defaults to 0 dB (a multiplier of
1.0) that the driver provides no way to change. The volume level
recorded in the MPEG stream is at the same level as it comes out of the
tuner - not very loud.


> Restoring stereo:
> # v4l2-dbg -c host0 -s 0x2c72014 0xb20
> (not 0xb25, to restore original value)
> Register 0x02c72014 set to 0xb20
>
> # v4l2-dbg -c host0 -g 0x2c72014
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72014 = 320h (800d 00000011 00100000b)
>
> So what are bits 0 and 2 to that register? Should I try setting the value
> to 0xb25 and seeing if that allows me to get stereo without static?

No. I have almost no documentation on that register.

I can tell you about bits 4-5 as the driver manipulates those in
cx18-audio.c:

00 - I2S Input 1 audio samples are routed to the MPEG encoder
(CX18_AV_AUDIO_SERIAL1 in cx18-cards.c)

01 - I2S Input 2 audio samples are routed to the MPEG encoder
(CX18_AV_AUDIO_SERIAL2 in cx18-cards.c)

10 - Audio samples from the SIF audio/broadcast decoder are routed
to the MPEG encoder.
(CX18_AV_AUDIOn in cx18-cards.c)


As for the rest of the bits, from experimentation I found that the
CX23418 will change the low nibble all on its own and that messing with
the low nibble will screw up good audio.


> I understand (at least the bit about life being busy). And let me take this
> opportunity to say I really appreciate just how responsive you've been to my
> particular issue.

You're welcome.


> One thing I'm unclear about is whether you now think we have
> similar root causes.

No, we don't. My problem may have a root cause in analog tuner
configuration. I'll figure it out when it really bugs me, but I rarely
watch channel 32.


> If not, is there a chance that my problem is something that
> can, or should, be addressed in software, either kernel or user space. IOW,
> might there be an opportunity for me to help test a patch for this issue?

Yes. I have high confidence that we should be able to fix your problem
with software.


> > I also need to look at your other email, and ask some questions about
> > the cable box behavior.
>
> Whenever life's not too busy <vbg>. Although I would like to know if it would be
> a total waste of my time to test my HVR-1600 in the old computer using WinXP and
> Linux with the latest drivers. If not, it's something I can do before I hand the
> machine over to my sister.\ this weekend.

Just to conclusively eliminate the possibility of a defective card by
testing under Windows XP. I suspect the card is *not* defective.

-Andy




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

Hi Andy,

I finally got to test my HVR-1600 under WinXP using Hauppauge's WinTV
application in my old computer. As you suspected, the audio was static
free. I can also confirm that the static occurs on a 32 bit kernel with
the drivers as of April 14 on the same computer, and if I boot back into
WinXP, the audio is fine. I'm relieved because that seems to rule out
hardware as a root cause. IOW it's unlikely my HVR-1600 or my new
computer with the ASUS M3N78 PRO mobo are at fault.

My next step will be to test the card in the new computer with the
cx18-init-debug repo, probably early next week.

Have a good weekend,
Helen

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

Hi,

Just to confirm, the mono register hack thing worked for me too. I really
do wish there was a way to fix that cs5345 volume control though, so that
it's not so quiet.

-Terry


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