Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ivtv: users

Sound died on hvr-1600

  

 
ivtv users RSS feed   Index | Next | Previous | View Threaded


DEPontius at edgehp

May 30, 2010, 7:56 AM

Post #1 of 19 (2366 views)
Permalink
Sound died on hvr-1600
Last week the audio died on one of my hvr-1600s. I'm limping along on
one at the moment, but don't plan to continue that way.

Time to start looking for a replacement? Or is there something I can do
to bring back the sound?

We had an early morning power outage. I brought the system back up, and
because everyone else was asleep, when I was checking for "red screen" I
had the sound turned off, and didn't notice any problem. My wife
noticed when she tried to watch one of her shows, and had no sound. I
rebooted and brought sound back, but only that once. Next boot, no
sound, and full power disconnection doesn't bring sound back, either.
(Full power disconnection has always brought back "red screen" to full
function.)

In another week or two I'm taking the system down to change some other
components, and at that point I'll replug both hvr-1600s, to see if that
helps at all. If it doesn't, it's time to order.

What to order?

I don't remember what model hvr-1600 I have, but a little quick
searching gives 1101, 1178, 1183, and 1199, all at slightly different
price points. The 1178 and 1199 look more like what I've got - the 1101
and 1183 seem to be missing my IR/audio mini-jacks, having what look
like a pair of RCA jacks (stereo audio?) instead. From what I can tell:
The 1101 comes with no remote, seems to have 3 antenna inputs.
The 1178 looks most like what I've got.
The 1183 has a separate USB remote, again 3 antenna inputs.
The 1199 looks like what I've got, but also has FM.

Is another hvr-1600 really the best thing to get? I'm set up for it,
and it meets my needs pretty well. At the moment I'm really only using
the analog side, and experimenting with the digital side. I'm also on
Comcast, and have no idea when they're going to do something annoying.

Incidentally, regarding the "red screen", which I've reported before:
At this point, the "red screen" appears to be something that happens at
boot time, I have no solid evidence of a properly working system that
subsequently went into "red screen" mode. Full power-off, either unplug
or the "hard" switch on the power supply in back, has always fixed it.
One possible, slight correlation... I have grub set for a 30-second
boot delay. Pressing "enter" to speed boot might aggravate "red
screen", and waiting for the full timeout may make it less likely, but
once it has hit, it takes a full power-off to recover.

Thanks,
Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

May 30, 2010, 12:16 PM

Post #2 of 19 (2325 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Sun, 2010-05-30 at 10:56 -0400, Dale Pontius wrote:
> Last week the audio died on one of my hvr-1600s. I'm limping along on
> one at the moment, but don't plan to continue that way.
>
> Time to start looking for a replacement? Or is there something I can do
> to bring back the sound?

Maybe.

Does the audio line input still work for sound?

When tuned to a known good channel, what does v4l2-ctl --log-status show
for the detected Audio Standard on each HVR-1600?


> We had an early morning power outage. I brought the system back up, and
> because everyone else was asleep, when I was checking for "red screen" I
> had the sound turned off, and didn't notice any problem. My wife
> noticed when she tried to watch one of her shows, and had no sound. I
> rebooted and brought sound back, but only that once. Next boot, no
> sound, and full power disconnection doesn't bring sound back, either.
> (Full power disconnection has always brought back "red screen" to full
> function.)

Given all the problems people have reported with braodcast audio
decoding by the stand-alone CX25843 and the CX23418's integrated CX25843
core, I'm under the impression the core doesn't perform well with the RF
signal characteristics cable companies or STB's seem to provide.

The CX25843 and CX23418's integrated CX25843 had never given me a
problem with OTA broadcast analog signals.



> In another week or two I'm taking the system down to change some other
> components, and at that point I'll replug both hvr-1600s, to see if that
> helps at all. If it doesn't, it's time to order.

Blow the dust out of every slot while you're at it.


> What to order?
>
> I don't remember what model hvr-1600 I have, but a little quick
> searching gives 1101, 1178, 1183, and 1199, all at slightly different
> price points. The 1178 and 1199 look more like what I've got - the 1101
> and 1183 seem to be missing my IR/audio mini-jacks, having what look
> like a pair of RCA jacks (stereo audio?) instead. From what I can tell:
> The 1101 comes with no remote, seems to have 3 antenna inputs.
> The 1178 looks most like what I've got.
> The 1183 has a separate USB remote, again 3 antenna inputs.
> The 1199 looks like what I've got, but also has FM.
>
> Is another hvr-1600 really the best thing to get? I'm set up for it,
> and it meets my needs pretty well. At the moment I'm really only using
> the analog side, and experimenting with the digital side. I'm also on
> Comcast, and have no idea when they're going to do something annoying.

Well, PCI bus equipment is being phased out in favor of PCIe in the
consumer market. Finding newer card designs (i.e. PCIe) with good
analog support under linux is hard. (Do you want reliability and
usability, or do you want maintainability. ;] )

Boards based on the CX2388[578] PCIe bridge chips can have raw analog
hookups and can also have an onborad CX23417 to perform hardware MPEG
compression. However, Linux support for these boards for analog video
is well, barely useable. The CX2388[578] also has essentially an
integrated CX25843 as well, so any analog sound decoding problems you
have now (caused by external factors), these chips may also exhibit.


USB is a nicer choice in my opinion. External to the PC case means
less EMI affecting the tuner. Also they are easily moved from one
machine to the next for troubleshooting, etc.

If you want hardware MPEG encoding from a USB device with essentially
the same "guts" as the PVR-150 or HVR-1600, the HVR-1950, supported by
the pvrusb2 driver, comes to mind.
http://www.isely.net/pvrusb2/pvrusb2.html
(FM radio not supported under linux.)

If you want H.264 compression in hardware from a USB device, people have
been very happy with the HD-PVR. Note that the HD-PVR appears to be the
only consumer product currently available that lets you caputre analog
HD (resolutions better than 480i). This unit doesn't have a tuner, so
you'll need to feed it either baseband Composite video, S Video, or
Component video, and basedband audio. This unit probably offers a
longer usable life, as it makes one's video capture setup more modular
(the tuning function is handled by a VCR, STB, or something else, the
bus interface is USB) so this unit can stay as a usable component as TV
tuner and PC IO bus technologies evolve.

And the wiki of course has information:
http://www.linuxtv.org/wiki/index.php/Hardware_Device_Information
http://www.mythtv.org/wiki/Video_capture_card


> Incidentally, regarding the "red screen", which I've reported before:
> At this point, the "red screen" appears to be something that happens at
> boot time, I have no solid evidence of a properly working system that
> subsequently went into "red screen" mode. Full power-off, either unplug
> or the "hard" switch on the power supply in back, has always fixed it.
> One possible, slight correlation... I have grub set for a 30-second
> boot delay. Pressing "enter" to speed boot might aggravate "red
> screen", and waiting for the full timeout may make it less likely, but
> once it has hit, it takes a full power-off to recover.
>
> Thanks,
> Dale Pontius



_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

May 30, 2010, 7:18 PM

Post #3 of 19 (2321 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 05/30/10 15:16, Andy Walls wrote:
> On Sun, 2010-05-30 at 10:56 -0400, Dale Pontius wrote:
>> Last week the audio died on one of my hvr-1600s. I'm limping along on
>> one at the moment, but don't plan to continue that way.
>>
>> Time to start looking for a replacement? Or is there something I can do
>> to bring back the sound?
>
> Maybe.
>
> Does the audio line input still work for sound?
>
Haven't/can't try it. See next comment.

> When tuned to a known good channel, what does v4l2-ctl --log-status show
> for the detected Audio Standard on each HVR-1600?
>
I need to go back through the list and dig up your link to the code.
I'm running Gentoo, and v4l2-ctl is part of the ivtv-tools package. I'm
not sure if it's because I'm running cx18 instead of ivtv, or if it's
because I'm running cx18 out-of-tree, direct from v4l mercurial, but
Gentoo won't let me build it. Getting around this was one of those
things on my round tuit list - now it's a bit more important. I had
v4l2-ctl when you were helping me originally because Gentoo had those
packages organized differently, then.
>
>> We had an early morning power outage. I brought the system back up, and
>> because everyone else was asleep, when I was checking for "red screen" I
>> had the sound turned off, and didn't notice any problem. My wife
>> noticed when she tried to watch one of her shows, and had no sound. I
>> rebooted and brought sound back, but only that once. Next boot, no
>> sound, and full power disconnection doesn't bring sound back, either.
>> (Full power disconnection has always brought back "red screen" to full
>> function.)
>
> Given all the problems people have reported with braodcast audio
> decoding by the stand-alone CX25843 and the CX23418's integrated CX25843
> core, I'm under the impression the core doesn't perform well with the RF
> signal characteristics cable companies or STB's seem to provide.
>
> The CX25843 and CX23418's integrated CX25843 had never given me a
> problem with OTA broadcast analog signals.
>
I still tend to think it's a problem on the card. When it was working,
I had no complaints. The other card is still working, and I have no
complaints. Video still works on this card, no problems. If it were
signal, I would expect to see some degradation somewhere, not a simple
binary works/doesn't-work, as this is.

I was hoping that I could just flip the mystery-bit, and it would come back.
>
>
>> In another week or two I'm taking the system down to change some other
>> components, and at that point I'll replug both hvr-1600s, to see if that
>> helps at all. If it doesn't, it's time to order.
>
> Blow the dust out of every slot while you're at it.
>
I'll make sure I have dust-off on hand. I have some, not sure how full.
>
>> What to order?
>>
>> I don't remember what model hvr-1600 I have, but a little quick
>> searching gives 1101, 1178, 1183, and 1199, all at slightly different
>> price points. The 1178 and 1199 look more like what I've got - the 1101
>> and 1183 seem to be missing my IR/audio mini-jacks, having what look
>> like a pair of RCA jacks (stereo audio?) instead. From what I can tell:
>> The 1101 comes with no remote, seems to have 3 antenna inputs.
>> The 1178 looks most like what I've got.
>> The 1183 has a separate USB remote, again 3 antenna inputs.
>> The 1199 looks like what I've got, but also has FM.
>>
>> Is another hvr-1600 really the best thing to get? I'm set up for it,
>> and it meets my needs pretty well. At the moment I'm really only using
>> the analog side, and experimenting with the digital side. I'm also on
>> Comcast, and have no idea when they're going to do something annoying.
>
> Well, PCI bus equipment is being phased out in favor of PCIe in the
> consumer market. Finding newer card designs (i.e. PCIe) with good
> analog support under linux is hard. (Do you want reliability and
> usability, or do you want maintainability. ;] )
>
> Boards based on the CX2388[578] PCIe bridge chips can have raw analog
> hookups and can also have an onborad CX23417 to perform hardware MPEG
> compression. However, Linux support for these boards for analog video
> is well, barely useable. The CX2388[578] also has essentially an
> integrated CX25843 as well, so any analog sound decoding problems you
> have now (caused by external factors), these chips may also exhibit.
>
I wish Hauppauge would come clean on this - better yet, help a little
with the necessary information.
>
> USB is a nicer choice in my opinion. External to the PC case means
> less EMI affecting the tuner. Also they are easily moved from one
> machine to the next for troubleshooting, etc.
>
> If you want hardware MPEG encoding from a USB device with essentially
> the same "guts" as the PVR-150 or HVR-1600, the HVR-1950, supported by
> the pvrusb2 driver, comes to mind.
> http://www.isely.net/pvrusb2/pvrusb2.html
> (FM radio not supported under linux.)
>
That looks interesting. A little more expensive, but might well be
worth it.

> If you want H.264 compression in hardware from a USB device, people have
> been very happy with the HD-PVR. Note that the HD-PVR appears to be the
> only consumer product currently available that lets you caputre analog
> HD (resolutions better than 480i). This unit doesn't have a tuner, so
> you'll need to feed it either baseband Composite video, S Video, or
> Component video, and basedband audio. This unit probably offers a
> longer usable life, as it makes one's video capture setup more modular
> (the tuning function is handled by a VCR, STB, or something else, the
> bus interface is USB) so this unit can stay as a usable component as TV
> tuner and PC IO bus technologies evolve.
>
I'll have to think about that one. I've heard a lot of talk about the
HD-PVR, most of it good, much of it fear about "closing the analog
hole." My current STB (and Comcast plan) only supports std-def, so the
ClearQAM gives me a way to get some direct digital.

I've played a bit with ClearQAM, I've done very little with the STB.
I'm more than a little fearful of finding the right lirc config to make
it work. Piling that on top of the complexity of getting the hvr-1600
blaster working, and the time to do it all is what has stopped me.

> And the wiki of course has information:
> http://www.linuxtv.org/wiki/index.php/Hardware_Device_Information
> http://www.mythtv.org/wiki/Video_capture_card
>
I'll walk through all of this again. Haven't really looked since
getting the hvr-1600s.

Thanks,
Dale

>
>> Incidentally, regarding the "red screen", which I've reported before:
>> At this point, the "red screen" appears to be something that happens at
>> boot time, I have no solid evidence of a properly working system that
>> subsequently went into "red screen" mode. Full power-off, either unplug
>> or the "hard" switch on the power supply in back, has always fixed it.
>> One possible, slight correlation... I have grub set for a 30-second
>> boot delay. Pressing "enter" to speed boot might aggravate "red
>> screen", and waiting for the full timeout may make it less likely, but
>> once it has hit, it takes a full power-off to recover.

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 1, 2010, 5:37 PM

Post #4 of 19 (2336 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 05/30/10 15:16, Andy Walls wrote:
> On Sun, 2010-05-30 at 10:56 -0400, Dale Pontius wrote:
>> Last week the audio died on one of my hvr-1600s. I'm limping along on
>> one at the moment, but don't plan to continue that way.
>>
>> Time to start looking for a replacement? Or is there something I can do
>> to bring back the sound?
>
> Maybe.
>
> Does the audio line input still work for sound?
>
> When tuned to a known good channel, what does v4l2-ctl --log-status show
> for the detected Audio Standard on each HVR-1600?
>
For the good card - /dev/video1 :

Status Log:

cx18-1: ================= START STATUS CARD #1 =================
cx18-1: Version: 1.4.0 Card: Hauppauge HVR-1600
tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 3334244
tveeprom 4-0050: MAC address is 00:0d:fe:32:e0:64
tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 4-0050: audio processor is CX23418 (idx 38)
tveeprom 4-0050: decoder processor is CX23418 (idx 31)
tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter
cx18-1 843: Video signal: present
cx18-1 843: Detected format: NTSC-M
cx18-1 843: Specified standard: NTSC-M
cx18-1 843: Specified video input: Composite 7
cx18-1 843: Specified audioclock freq: 48000 Hz
cx18-1 843: Detected audio mode: stereo
cx18-1 843: Detected audio standard: BTSC
cx18-1 843: Audio muted: no
cx18-1 843: Audio microcontroller: running
cx18-1 843: Configured audio standard: automatic detection
cx18-1 843: Configured audio system: BTSC
cx18-1 843: Specified audio input: Tuner (In8)
cx18-1 843: Preferred audio mode: stereo
cx18-1 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
tuner 5-0061: Tuner mode: analog TV
tuner 5-0061: Frequency: 499.25 MHz
tuner 5-0061: Standard: 0x0000b000
cs5345 4-004c: Input: 1
cs5345 4-004c: Volume: 0 dB
cx18-1: Video Input: Tuner 1
cx18-1: Audio Input: Tuner 1
cx18-1: GPIO: direction 0x00003001, value 0x00003001
cx18-1: Tuner: TV
cx18-1: Stream: MPEG-2 Program Stream
cx18-1: VBI Format: No VBI
cx18-1: Video: 720x480, 30 fps
cx18-1: Video: MPEG-2, 4x3, Variable Bitrate, 4500000, Peak 6000000
cx18-1: Video: GOP Size 15, 2 B-Frames, GOP Closure
cx18-1: Audio: 48 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No
Emphasis, No CRC
cx18-1: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D
Horizontal, 0
cx18-1: Temporal Filter: Manual, 8
cx18-1: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
cx18-1: Status flags: 0x00200001
cx18-1: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64
buffers) in use
cx18-1: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
buffers) in use
cx18-1: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20
buffers) in use
cx18-1: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256
buffers) in use
cx18-1: Read MPEG/VBI: 2333106176/0 bytes
cx18-1: ================== END STATUS CARD #1 ==================

and for the bad card - /dev/video0 :

Status Log:

cx18-0: ================= START STATUS CARD #0 =================
cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
tveeprom 2-0050: Hauppauge model 74041, rev C6B2, serial# 3335430
tveeprom 2-0050: MAC address is 00:0d:fe:32:e5:06
tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 2-0050: audio processor is CX23418 (idx 38)
tveeprom 2-0050: decoder processor is CX23418 (idx 31)
tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
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: mono
cx18-0 843: Detected audio standard: no detected audio standard
cx18-0 843: Audio muted: yes
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
tuner 3-0061: Tuner mode: analog TV
tuner 3-0061: Frequency: 67.25 MHz
tuner 3-0061: Standard: 0x00001000
cs5345 2-004c: Input: 1
cs5345 2-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 0x0000, 0% of 2048 KiB (64
buffers) in use
cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
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: 3926016/0 bytes
cx18-0: ================== END STATUS CARD #0 ==================

So it's immediately obvious that something is different about the audio.
I don't yet see a v4l2-ctl option to un-mute the audio, but I don't
think that's really the problem. I would expect muting to be an output
function, and at any rate the audio standard should have been correctly
detected.

Getting something into the svideo/audio inputs will take a little more
round-tuit work that I've been meaning to do for a long time. This may
constitute extra incentive.

Thanks,
Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


drescherjm at gmail

Jun 1, 2010, 6:00 PM

Post #5 of 19 (2310 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
> I need to go back through the list and dig up your link to the code.
> I'm running Gentoo, and v4l2-ctl is part of the ivtv-tools package.  I'm
> not sure if it's because I'm running cx18 instead of ivtv, or if it's
> because I'm running cx18 out-of-tree, direct from v4l mercurial, but
> Gentoo won't let me build it.  Getting around this was one of those
> things on my round tuit list - now it's a bit more important.

Have you tried http://gentoo-portage.com/media-tv/v4l-dvb-hg

I have used that for years with gentoo with my pvr-150, 250 and 500
and also my kworld atsc/qam card.

John

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 1, 2010, 6:56 PM

Post #6 of 19 (2302 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/01/10 21:00, John Drescher wrote:
>> I need to go back through the list and dig up your link to the code.
>> I'm running Gentoo, and v4l2-ctl is part of the ivtv-tools package. I'm
>> not sure if it's because I'm running cx18 instead of ivtv, or if it's
>> because I'm running cx18 out-of-tree, direct from v4l mercurial, but
>> Gentoo won't let me build it. Getting around this was one of those
>> things on my round tuit list - now it's a bit more important.
>
> Have you tried http://gentoo-portage.com/media-tv/v4l-dvb-hg
>
> I have used that for years with gentoo with my pvr-150, 250 and 500
> and also my kworld atsc/qam card.
>
No, didn't know about that one. This evening I built the tools Andy had
a link to, and managed to get v4l2-ctl from there. I would really
rather get it out of portage, though. I need to look at that one. I've
been running cx18 out-of-tree, out-of-portage also. I think I've seen a
cx18 in portage, again a "-hg" build, but haven't tried it. (What I
have has been working too well to mess around.)

Dale

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


drescherjm at gmail

Jun 1, 2010, 7:22 PM

Post #7 of 19 (2304 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Tue, Jun 1, 2010 at 9:56 PM, Dale Pontius <DEPontius [at] edgehp> wrote:
> On 06/01/10 21:00, John Drescher wrote:
>>> I need to go back through the list and dig up your link to the code.
>>> I'm running Gentoo, and v4l2-ctl is part of the ivtv-tools package.  I'm
>>> not sure if it's because I'm running cx18 instead of ivtv, or if it's
>>> because I'm running cx18 out-of-tree, direct from v4l mercurial, but
>>> Gentoo won't let me build it.  Getting around this was one of those
>>> things on my round tuit list - now it's a bit more important.
>>
>> Have you tried http://gentoo-portage.com/media-tv/v4l-dvb-hg
>>
>> I have used that for years with gentoo with my pvr-150, 250 and 500
>> and also my kworld atsc/qam card.
>>
> No, didn't know about that one.  This evening I built the tools Andy had
> a link to, and managed to get v4l2-ctl from there.  I would really
> rather get it out of portage, though.  I need to look at that one.  I've
> been running cx18 out-of-tree, out-of-portage also.  I think I've seen a
> cx18 in portage, again a "-hg" build, but haven't tried it.  (What I
> have has been working too well to mess around.)
>
That is for the drivers. Sorry. There are other ebuilds for the
various tools. And like you said ivtv-utils provides v4l2-ctl


jmd0 ~ # equery belongs v4l2-ctl
* Searching for v4l2-ctl ...
media-tv/ivtv-utils-1.4.0 (/usr/bin/v4l2-ctl)

John

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

Jun 4, 2010, 6:42 PM

Post #8 of 19 (2264 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Tue, 2010-06-01 at 20:37 -0400, Dale Pontius wrote:
> On 05/30/10 15:16, Andy Walls wrote:
> > On Sun, 2010-05-30 at 10:56 -0400, Dale Pontius wrote:
> >> Last week the audio died on one of my hvr-1600s. I'm limping along on
> >> one at the moment, but don't plan to continue that way.
> >>
> >> Time to start looking for a replacement? Or is there something I can do
> >> to bring back the sound?
> >
> > Maybe.
> >
> > Does the audio line input still work for sound?
> >
> > When tuned to a known good channel, what does v4l2-ctl --log-status show
> > for the detected Audio Standard on each HVR-1600?
> >
> For the good card - /dev/video1 :
>
> Status Log:
>
> cx18-1: ================= START STATUS CARD #1 =================
> cx18-1: Version: 1.4.0 Card: Hauppauge HVR-1600
> tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 3334244
> tveeprom 4-0050: MAC address is 00:0d:fe:32:e0:64
> tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
> tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
> tveeprom 4-0050: audio processor is CX23418 (idx 38)
> tveeprom 4-0050: decoder processor is CX23418 (idx 31)
> tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter
> cx18-1 843: Video signal: present
> cx18-1 843: Detected format: NTSC-M
> cx18-1 843: Specified standard: NTSC-M
> cx18-1 843: Specified video input: Composite 7
> cx18-1 843: Specified audioclock freq: 48000 Hz
> cx18-1 843: Detected audio mode: stereo
> cx18-1 843: Detected audio standard: BTSC
> cx18-1 843: Audio muted: no
> cx18-1 843: Audio microcontroller: running
> cx18-1 843: Configured audio standard: automatic detection
> cx18-1 843: Configured audio system: BTSC
> cx18-1 843: Specified audio input: Tuner (In8)
> cx18-1 843: Preferred audio mode: stereo
> cx18-1 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
> tuner 5-0061: Tuner mode: analog TV
> tuner 5-0061: Frequency: 499.25 MHz
> tuner 5-0061: Standard: 0x0000b000
> cs5345 4-004c: Input: 1
> cs5345 4-004c: Volume: 0 dB
> cx18-1: Video Input: Tuner 1
> cx18-1: Audio Input: Tuner 1
> cx18-1: GPIO: direction 0x00003001, value 0x00003001
> cx18-1: Tuner: TV
> cx18-1: Stream: MPEG-2 Program Stream
> cx18-1: VBI Format: No VBI
> cx18-1: Video: 720x480, 30 fps
> cx18-1: Video: MPEG-2, 4x3, Variable Bitrate, 4500000, Peak 6000000
> cx18-1: Video: GOP Size 15, 2 B-Frames, GOP Closure
> cx18-1: Audio: 48 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No
> Emphasis, No CRC
> cx18-1: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D
> Horizontal, 0
> cx18-1: Temporal Filter: Manual, 8
> cx18-1: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
> cx18-1: Status flags: 0x00200001
> cx18-1: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64
> buffers) in use
> cx18-1: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
> buffers) in use
> cx18-1: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20
> buffers) in use
> cx18-1: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256
> buffers) in use
> cx18-1: Read MPEG/VBI: 2333106176/0 bytes
> cx18-1: ================== END STATUS CARD #1 ==================
>
> and for the bad card - /dev/video0 :
>
> Status Log:
>
> cx18-0: ================= START STATUS CARD #0 =================
> cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
> tveeprom 2-0050: Hauppauge model 74041, rev C6B2, serial# 3335430
> tveeprom 2-0050: MAC address is 00:0d:fe:32:e5:06
> tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
> tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
> tveeprom 2-0050: audio processor is CX23418 (idx 38)
> tveeprom 2-0050: decoder processor is CX23418 (idx 31)
> tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
> 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: mono
> cx18-0 843: Detected audio standard: no detected audio standard
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
And this is what makes me pull my hair out. ----+

Same card, same chipset, same firmware image, in the same PC and mobo,
same TV channel with the same RF signal, same analog tuner assembly, and
one '843 core detects the audio standard and the other '843 core
doesn't. :P

If you have controlled the signal levels properly and used good cable
and grounding, the difference has to be in the analog tuner can. Either
it has gone bad, or it is picking up a lot of noise from somewhere.

Come to think of it, a bad analog tuner assembly could explain the red
screen.

Anyway, if *everthing* is the same, and one card works and one card
doesn't, there's nothing to be done in software - except implement
workaround that may not work. I *speculate* that you have a dying card.



> cx18-0 843: Audio muted: yes
> 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
> tuner 3-0061: Tuner mode: analog TV
> tuner 3-0061: Frequency: 67.25 MHz
> tuner 3-0061: Standard: 0x00001000
> cs5345 2-004c: Input: 1
> cs5345 2-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 0x0000, 0% of 2048 KiB (64
> buffers) in use
> cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
> 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: 3926016/0 bytes
> cx18-0: ================== END STATUS CARD #0 ==================
>
> So it's immediately obvious that something is different about the audio.
> I don't yet see a v4l2-ctl option to un-mute the audio, but I don't
> think that's really the problem. I would expect muting to be an output
> function, and at any rate the audio standard should have been correctly
> detected.


When the 8051 microcontroller embedded in the '843 core positively
identifies an audio standard (BTSC for boradcast NTSC), then it
configures the '843 registers and automatically unmutes the audio. (If
it were unmuted when detection was going on, you'd likely hear a lot of
static.)

Regards,
Andy


>
> Getting something into the svideo/audio inputs will take a little more
> round-tuit work that I've been meaning to do for a long time. This may
> constitute extra incentive.
>
> Thanks,
> Dale Pontius



_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 6, 2010, 7:16 PM

Post #9 of 19 (2243 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/04/10 21:42, Andy Walls wrote:
> On Tue, 2010-06-01 at 20:37 -0400, Dale Pontius wrote:
>> On 05/30/10 15:16, Andy Walls wrote:
>>> On Sun, 2010-05-30 at 10:56 -0400, Dale Pontius wrote:
>>>> Last week the audio died on one of my hvr-1600s. I'm limping along on
>>>> one at the moment, but don't plan to continue that way.
>>>>
>>>> Time to start looking for a replacement? Or is there something I can do
>>>> to bring back the sound?
>>>
>>> Maybe.
>>>
>>> Does the audio line input still work for sound?
>>>
>>> When tuned to a known good channel, what does v4l2-ctl --log-status show
>>> for the detected Audio Standard on each HVR-1600?
>>>
>> For the good card - /dev/video1 :
>>
>> Status Log:
>>
>> cx18-1: ================= START STATUS CARD #1 =================
>> cx18-1: Version: 1.4.0 Card: Hauppauge HVR-1600
>> tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 3334244
>> tveeprom 4-0050: MAC address is 00:0d:fe:32:e0:64
>> tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
>> tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
>> tveeprom 4-0050: audio processor is CX23418 (idx 38)
>> tveeprom 4-0050: decoder processor is CX23418 (idx 31)
>> tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter
>> cx18-1 843: Video signal: present
>> cx18-1 843: Detected format: NTSC-M
>> cx18-1 843: Specified standard: NTSC-M
>> cx18-1 843: Specified video input: Composite 7
>> cx18-1 843: Specified audioclock freq: 48000 Hz
>> cx18-1 843: Detected audio mode: stereo
>> cx18-1 843: Detected audio standard: BTSC
>> cx18-1 843: Audio muted: no
>> cx18-1 843: Audio microcontroller: running
>> cx18-1 843: Configured audio standard: automatic detection
>> cx18-1 843: Configured audio system: BTSC
>> cx18-1 843: Specified audio input: Tuner (In8)
>> cx18-1 843: Preferred audio mode: stereo
>> cx18-1 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
>> tuner 5-0061: Tuner mode: analog TV
>> tuner 5-0061: Frequency: 499.25 MHz
>> tuner 5-0061: Standard: 0x0000b000
>> cs5345 4-004c: Input: 1
>> cs5345 4-004c: Volume: 0 dB
>> cx18-1: Video Input: Tuner 1
>> cx18-1: Audio Input: Tuner 1
>> cx18-1: GPIO: direction 0x00003001, value 0x00003001
>> cx18-1: Tuner: TV
>> cx18-1: Stream: MPEG-2 Program Stream
>> cx18-1: VBI Format: No VBI
>> cx18-1: Video: 720x480, 30 fps
>> cx18-1: Video: MPEG-2, 4x3, Variable Bitrate, 4500000, Peak 6000000
>> cx18-1: Video: GOP Size 15, 2 B-Frames, GOP Closure
>> cx18-1: Audio: 48 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No
>> Emphasis, No CRC
>> cx18-1: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D
>> Horizontal, 0
>> cx18-1: Temporal Filter: Manual, 8
>> cx18-1: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
>> cx18-1: Status flags: 0x00200001
>> cx18-1: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64
>> buffers) in use
>> cx18-1: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
>> buffers) in use
>> cx18-1: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20
>> buffers) in use
>> cx18-1: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256
>> buffers) in use
>> cx18-1: Read MPEG/VBI: 2333106176/0 bytes
>> cx18-1: ================== END STATUS CARD #1 ==================
>>
>> and for the bad card - /dev/video0 :
>>
>> Status Log:
>>
>> cx18-0: ================= START STATUS CARD #0 =================
>> cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
>> tveeprom 2-0050: Hauppauge model 74041, rev C6B2, serial# 3335430
>> tveeprom 2-0050: MAC address is 00:0d:fe:32:e5:06
>> tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
>> tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
>> tveeprom 2-0050: audio processor is CX23418 (idx 38)
>> tveeprom 2-0050: decoder processor is CX23418 (idx 31)
>> tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
>> 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: mono
>> cx18-0 843: Detected audio standard: no detected audio standard
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> And this is what makes me pull my hair out. ----+
>
> Same card, same chipset, same firmware image, in the same PC and mobo,
> same TV channel with the same RF signal, same analog tuner assembly, and
> one '843 core detects the audio standard and the other '843 core
> doesn't. :P
>
> If you have controlled the signal levels properly and used good cable
> and grounding, the difference has to be in the analog tuner can. Either
> it has gone bad, or it is picking up a lot of noise from somewhere.
>
> Come to think of it, a bad analog tuner assembly could explain the red
> screen.
>
> Anyway, if *everthing* is the same, and one card works and one card
> doesn't, there's nothing to be done in software - except implement
> workaround that may not work. I *speculate* that you have a dying card.
>
A few months back, I installed a new distribution amp, and at the same
time rebuilt all of the cables in RG6-quad with compression fittings,
etc. One test I could try is swapping the inputs on the two cards, to
see if any symptoms move. I tend to agree about the dying card. All
has been happy for many months after the input rebuild, and I haven't
touched anything significant lately. MythTV was upgraded to 0.22 in
March, and kernel and cx-18 drivers are both dated Feb 20.

Incidentally, on the last reboot audio came back on the card, and has
stayed back. I still haven't re-enabled it in MythTV, but keep checking
it every few days to make sure it hasn't gone bad, again. I have a
conflict on June 18, and if it's still working the, I'll re-enable it.

By then I may also have stuff around the house under control, and it'll
be time to take this machine down. Got a new CPU a while back - about
20% speed boost, for $5.00 at a flea market, adding another Gig of DRAM
from a different machine I'm decommissioning - and I'll remove,
dust-out, and reseat both capture cards.

I get more fearful about semiconductors and their longevity every
generation. I'm working in 32nM these days - hard to believe,
considering I started by testing 4-mask metal gate over 30 years ago.

Thanks,
Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 7, 2010, 6:26 PM

Post #10 of 19 (2224 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/04/10 21:42, Andy Walls wrote:
<snip>
>> 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: mono
>> cx18-0 843: Detected audio standard: no detected audio standard
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> And this is what makes me pull my hair out. ----+
>
> Same card, same chipset, same firmware image, in the same PC and mobo,
> same TV channel with the same RF signal, same analog tuner assembly, and
> one '843 core detects the audio standard and the other '843 core
> doesn't. :P
>
> If you have controlled the signal levels properly and used good cable
> and grounding, the difference has to be in the analog tuner can. Either
> it has gone bad, or it is picking up a lot of noise from somewhere.
>
> Come to think of it, a bad analog tuner assembly could explain the red
> screen.
>
> Anyway, if *everthing* is the same, and one card works and one card
> doesn't, there's nothing to be done in software - except implement
> workaround that may not work. I *speculate* that you have a dying card.
>
Another data point... I just checked again, and audio is still working
on that card. Thinking back, I don't believe I can ever positively
point to a time when either card "went bad" once it had initialized
correctly. When the red screen problems started, I hadn't done any
clear digging about when it had started. Once I recognized the red
screen, I only even found it after boot. The hard power off has always
worked to recover a red screen after boot, and since adopting this
procedure I have never seen it come back once properly initialized.

With the audio problem, my wife noticed the silent show, and I tracked
it back approximately to that morning's boot. I can't say precisely
because some shows did record with sound, but I believe those were
recorded on the other card. It's hard to tell afterward. Now after a
week without audio on the first card, I rebooted a few days ago and have
had audio ever since.

I won't deny that I may have a dying card, but if so it appears that
initialization is the stress point, and it hasn't degraded to the point
of failure during normal operation.

It needs to be on tonight to record, and the next overnight recording is
Friday night. I may try shutting down Tues-Thurs seeing if full power
off all night has any effect.

Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


mcree at orcon

Jun 7, 2010, 7:33 PM

Post #11 of 19 (2226 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 8/06/2010, at 1:26 PM, Dale Pontius wrote:
> With the audio problem, my wife noticed the silent show, and I tracked
> it back approximately to that morning's boot.

Actually, when I think about it, I have just had that happen with my
PVR350 card a week or so ago. I was very surprised on viewing a
programme recorded earlier that day that there was no audio! I had
just rebooted the server with the PVR card. Once I discovered the
problem I kicked out the ivtv module (i.e. rmmod ivtv) and then
reinstalled it (modprobe ivtv) and then sound worked again. I think
it has happened twice over the last two or so weeks--the first time I
have ever noticed such a problem in a number of years of using the
card. I am running the latest kernel 2.6.34 (and prior to that I was
sometimes running 2.6.34-rcXes since I was testing some new
features). Maybe a problem in the kernel drivers?

Cheers
Michael.


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 9, 2010, 2:49 AM

Post #12 of 19 (2205 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/07/10 22:33, Michael Cree wrote:
> On 8/06/2010, at 1:26 PM, Dale Pontius wrote:
>> With the audio problem, my wife noticed the silent show, and I tracked
>> it back approximately to that morning's boot.
>
> Actually, when I think about it, I have just had that happen with my
> PVR350 card a week or so ago. I was very surprised on viewing a
> programme recorded earlier that day that there was no audio! I had just
> rebooted the server with the PVR card. Once I discovered the problem I
> kicked out the ivtv module (i.e. rmmod ivtv) and then reinstalled it
> (modprobe ivtv) and then sound worked again. I think it has happened
> twice over the last two or so weeks--the first time I have ever noticed
> such a problem in a number of years of using the card. I am running the
> latest kernel 2.6.34 (and prior to that I was sometimes running
> 2.6.34-rcXes since I was testing some new features). Maybe a problem in
> the kernel drivers?
My drivers came from the v4l mercurial, out-of-tree and are unchanged
from February. This is a recent development. I've got a few
experiments lined up, hopefully later today.

Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 9, 2010, 4:48 PM

Post #13 of 19 (2205 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/04/10 21:42, Andy Walls wrote:
<snip>
>> 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: mono
>> cx18-0 843: Detected audio standard: no detected audio standard
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> And this is what makes me pull my hair out. ----+
>
> Same card, same chipset, same firmware image, in the same PC and mobo,
> same TV channel with the same RF signal, same analog tuner assembly, and
> one '843 core detects the audio standard and the other '843 core
> doesn't. :P
>
> If you have controlled the signal levels properly and used good cable
> and grounding, the difference has to be in the analog tuner can. Either
> it has gone bad, or it is picking up a lot of noise from somewhere.
>
> Come to think of it, a bad analog tuner assembly could explain the red
> screen.
>
> Anyway, if *everthing* is the same, and one card works and one card
> doesn't, there's nothing to be done in software - except implement
> workaround that may not work. I *speculate* that you have a dying card.
>
To continue contributing to sales of Rogaine...

This evening I finally got a few minutes to rub together, so I've done
an experiment. I shut down mythbackend, then started rmmoding as much
of the cx18 stuff as I could positively identify using modules.dep. The
idea was to "shut off" the cards with nothing else significant going on
with the system, like a power-down or reboot. Then I modprobed cx18 and
checked the status of both video devices. Both came up properly, both
had sound. Tempting fate, I decided to try a reboot. Both cards came
up properly, good sound, no red screens.

Which makes me think back just a little bit...

A few weeks back we had a bit of a heat wave here in Vermont - 80s even.
The heat broke, and everything started cooling down after Friday, June
5th, in quite a marked way. (some 20 degrees cooler) Looking back I
see that I reported that the card "came back" on June 6. It came up OK
just now, and it's still cool.

I'm wondering if there's a temperature effect here. Temperature is
quite a significant factor in semiconductor performance. I'm going to
keep an eye on this, and if sound goes away when it gets hot, I'll turn
on the A/C for a few hours to cool the room and let the system thermally
soak, then try again.

To put this back into the "dying card" mindset, there are many failure
and degradation modes in semiconductors, but one of those mechanisms is
a threshold shift (Vt-shift) that tends to slow things down. Higher
temperatures generally slow things down. I'm wondering about putting
them both together.

How is audio initialization done? I know I've seen you give parameters
before to "slow things down", but don't know if that's relevant in this
case. The weather is warming up toward next week, so it might be a good
time to try some of these experiments.

Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

Jun 10, 2010, 8:14 PM

Post #14 of 19 (2178 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Wed, 2010-06-09 at 19:48 -0400, Dale Pontius wrote:
> On 06/04/10 21:42, Andy Walls wrote:
> <snip>
> >> 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: mono
> >> cx18-0 843: Detected audio standard: no detected audio standard
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > |
> > And this is what makes me pull my hair out. ----+
> >
> > Same card, same chipset, same firmware image, in the same PC and mobo,
> > same TV channel with the same RF signal, same analog tuner assembly, and
> > one '843 core detects the audio standard and the other '843 core
> > doesn't. :P
> >
> > If you have controlled the signal levels properly and used good cable
> > and grounding, the difference has to be in the analog tuner can. Either
> > it has gone bad, or it is picking up a lot of noise from somewhere.
> >
> > Come to think of it, a bad analog tuner assembly could explain the red
> > screen.
> >
> > Anyway, if *everthing* is the same, and one card works and one card
> > doesn't, there's nothing to be done in software - except implement
> > workaround that may not work. I *speculate* that you have a dying card.
> >
> To continue contributing to sales of Rogaine...
>
> This evening I finally got a few minutes to rub together, so I've done
> an experiment. I shut down mythbackend, then started rmmoding as much
> of the cx18 stuff as I could positively identify using modules.dep. The
> idea was to "shut off" the cards with nothing else significant going on
> with the system, like a power-down or reboot.

Hmmm. Once some of those components are powered and enabled by
software, they are never disabled. The digital tuner and demodulator
chips come to mind. I think the analog ones are always consuming power
(with slightly more power used when left tuned to higher channel
frequencies due to running the oscillators faster).

BTW, if from the v4l-dvb source code tree, as root you do

# killall pulseaudio; modprobe -r cx18-alsa
(repeat that until it removes the cx18-alsa module)
# make unload; make unload

That should unload all the modules for the video and dvb stuff.


> Then I modprobed cx18 and
> checked the status of both video devices. Both came up properly, both
> had sound. Tempting fate, I decided to try a reboot. Both cards came
> up properly, good sound, no red screens.
>
> Which makes me think back just a little bit...
>
> A few weeks back we had a bit of a heat wave here in Vermont - 80s even.
> The heat broke, and everything started cooling down after Friday, June
> 5th, in quite a marked way. (some 20 degrees cooler) Looking back I
> see that I reported that the card "came back" on June 6. It came up OK
> just now, and it's still cool.
>
> I'm wondering if there's a temperature effect here. Temperature is
> quite a significant factor in semiconductor performance. I'm going to
> keep an eye on this, and if sound goes away when it gets hot, I'll turn
> on the A/C for a few hours to cool the room and let the system thermally
> soak, then try again.
>
> To put this back into the "dying card" mindset, there are many failure
> and degradation modes in semiconductors, but one of those mechanisms is
> a threshold shift (Vt-shift) that tends to slow things down. Higher
> temperatures generally slow things down. I'm wondering about putting
> them both together.

The hottest part of the card dealing with the analog signal is the
analog tuner can. It has two chips in it: a mixer/oscillator and an IF
demodulator. I'm betting the IF demodulator is failing when getting too
hot. AFC and AGC do rely on thresholds, so maybe threshold shift
matters there.

Just put more fans in the PC chassis and be done with it. :)


> How is audio initialization done?

Well, there are a lot of things. Let me write out the RF-aduio chain:

Antenna cable
Tuner preselector band filters (VHF low, FM radio, VHF high, UHF)
Tuner 1st stage: oscillator. mixer, IF amplifier, and AGC
Tuner SAW IF filter
Tuner 2nd stage: AGC, AFC, sound IF output (and sound demod to mono AF - not used by driver but wired up)
External capacitors and resistors (block DC, meet impedance requirments, etc).
CX23418(CX25843) Analog front end: clamping, droop compensation, variable gain analog amp with AGC, and ADC
SIF measurement and decoding: 8051 microcontroller assisted/automated
Dematrix (stereo L R, SAP)
Basedband digital audio routing & processing: volume, balance, equalization, clamping, etc.
Sample rate conversion
Audio Input Mux 1: selects between '843 digital audio and external I2S digital audio
CX23418 APU input


In your failure case, the 8051 microcontroller had failed to detect BTSC
in the SIF. What should be really easy to find in the SIF for NTSC? A
BTSC signal - especially the FM modulated mono L+R channel.

Working backwards, that means either

1. the SIF measurement/analysis was bad (bad 8051 cx23418.dig firmware load?)
2. SIF analog to digital conversion was bad
3. SIF analog signal conditioning by the CX23418 analog front end and AGC was bad
4. external components between the tuner can and CX23418 charged up close to the rails, killing the SIF signal
5. the tuner IF demodulator output a useless SIF signal or failed to lock on to the sound carrier
6. the IF freq out of the mixer oscillator was off center, video passed through, but the 4.5 MHz sound carrier was filtered out
7. the mixer, oscillator was at the wrong freq, or locked on to a nearby intermodulation product (spur) as the pciture carrier instead of the actual picture carrier
8. Gremlins

It's easy enough to clip a scope probe on the leg of the tuner that has
the SIF signal on it to check at #5 above.

Regards,
Andy





> I know I've seen you give parameters
> before to "slow things down", but don't know if that's relevant in this
> case. The weather is warming up toward next week, so it might be a good
> time to try some of these experiments.
>
> Dale Pontius
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-users



_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 11, 2010, 7:03 PM

Post #15 of 19 (2164 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/10/10 23:14, Andy Walls wrote:
> On Wed, 2010-06-09 at 19:48 -0400, Dale Pontius wrote:
>> On 06/04/10 21:42, Andy Walls wrote:
>> <snip>
>>>> 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: mono
>>>> cx18-0 843: Detected audio standard: no detected audio standard
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> |
>>> And this is what makes me pull my hair out. ----+
>>>
>>> Same card, same chipset, same firmware image, in the same PC and mobo,
>>> same TV channel with the same RF signal, same analog tuner assembly, and
>>> one '843 core detects the audio standard and the other '843 core
>>> doesn't. :P
>>>
>>> If you have controlled the signal levels properly and used good cable
>>> and grounding, the difference has to be in the analog tuner can. Either
>>> it has gone bad, or it is picking up a lot of noise from somewhere.
>>>
>>> Come to think of it, a bad analog tuner assembly could explain the red
>>> screen.
>>>
>>> Anyway, if *everthing* is the same, and one card works and one card
>>> doesn't, there's nothing to be done in software - except implement
>>> workaround that may not work. I *speculate* that you have a dying card.
>>>
>> To continue contributing to sales of Rogaine...
>>
>> This evening I finally got a few minutes to rub together, so I've done
>> an experiment. I shut down mythbackend, then started rmmoding as much
>> of the cx18 stuff as I could positively identify using modules.dep. The
>> idea was to "shut off" the cards with nothing else significant going on
>> with the system, like a power-down or reboot.
>
> Hmmm. Once some of those components are powered and enabled by
> software, they are never disabled. The digital tuner and demodulator
> chips come to mind. I think the analog ones are always consuming power
> (with slightly more power used when left tuned to higher channel
> frequencies due to running the oscillators faster).
>
Thanks for all of the thought, but last night/today/just-now I think I
shot any theories full of holes.

The weather has been warming today, but last night I shut the computer
down. Regular shutdown, not full power-off, so 5VSB was still on, which
is at least significant to the red-screen. This morning, in the cold, I
powered on - no audio. A little later I rebooted, still no audio.

So much for it being largely about temperature.

It has warmed quite a bit today, and this evening I had a few minutes,
so I removed all of the modules, then modprobed cx18 and cx18-alsa. I
have sound, again.

It's just flakey. Maybe when I get a break and take this system down, a
bit of dust-off and reseating cards will work wonders.

I had been focusing on initialization, partly because when we're
analyzing, we analyze the major modes of operation practically to death,
especially the performance-critical ones. There are things you can do
to simulate end-of-life device shifts, etc, and we do those. For the
power circuitry you analyze power-up to death, too. But initialization
is one of those typically non-critical things that you logically verify.
Schedules are schedules, and you want to do a thorough job, but usually
something has to give, and it's the less-used stuff that hasn't failed
in the past. (The opposite is "analysis paralysis", where you keep
analyzing past the accuracy of your simulator to really tell you
anything. The ultimate judge is hardware. But then again, I've never
done consumer electronics, and maybe their mindset is different.

Thanks for all of your thought and consideration,
Dale

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

Jun 12, 2010, 5:42 AM

Post #16 of 19 (2150 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Fri, 2010-06-11 at 22:03 -0400, Dale Pontius wrote:
> On 06/10/10 23:14, Andy Walls wrote:

> Thanks for all of the thought, but last night/today/just-now I think I
> shot any theories full of holes.
>
> The weather has been warming today, but last night I shut the computer
> down. Regular shutdown, not full power-off, so 5VSB was still on, which
> is at least significant to the red-screen. This morning, in the cold, I
> powered on - no audio. A little later I rebooted, still no audio.
>
> So much for it being largely about temperature.
>
> It has warmed quite a bit today, and this evening I had a few minutes,
> so I removed all of the modules, then modprobed cx18 and cx18-alsa. I
> have sound, again.
>
> It's just flakey. Maybe when I get a break and take this system down, a
> bit of dust-off and reseating cards will work wonders.

Well, some things to try:

1. remove all instances of the cx18-alsa.ko module from
under /lib/modules. It shouldn't matter, but most users never need it,
If hald or pulseaudio has it open, you may be unable to switch away from
48 ksps and then back.

2. When you have no audio, try using v4l2-ctl to switch from the tuner
audio to line in audio and back. You could also stop then capture,
switch to 44.1 ksps or 32 ksps and then restart the capture.



> I had been focusing on initialization, partly because when we're
> analyzing, we analyze the major modes of operation practically to death,
> especially the performance-critical ones. There are things you can do
> to simulate end-of-life device shifts, etc, and we do those. For the
> power circuitry you analyze power-up to death, too. But initialization
> is one of those typically non-critical things that you logically verify.

Whenever I see

Verification method: inspection

in a design review, my internal alarm bells go off.

Unfortunately, without proper instrumentation and engineering
documentation, we're left with Easter-egg hunting for solutions. We can
narrow down the problem to "somewhere around here", but then we're stuck
trying a myriad of end user actions and hoping something works against
an intermittent problem. Lack of determinism in the problem and
process makes finding solutions a lengthy process.


> Schedules are schedules, and you want to do a thorough job, but usually
> something has to give, and it's the less-used stuff that hasn't failed
> in the past. (The opposite is "analysis paralysis", where you keep
> analyzing past the accuracy of your simulator to really tell you
> anything. The ultimate judge is hardware. But then again, I've never
> done consumer electronics, and maybe their mindset is different.

I don't know. With PC hardware, there's a really big waterfront in terms
of hardware permutations and parts quality. So the question becomes
"what hardware"? For example, you can search the list for how well a
CX23415/6 interacts with a VIA PCI chipset.

The difficulties caused by the number of possible hardware
permutationsat is managed in the Windows world by WHQL and OEMs putting
together media center PCs in only standard, known good configurations.

Regards,
Andy

> Thanks for all of your thought and consideration,
> Dale
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-users



_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

Jun 12, 2010, 6:05 AM

Post #17 of 19 (2149 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Tue, 2010-06-08 at 14:33 +1200, Michael Cree wrote:
> On 8/06/2010, at 1:26 PM, Dale Pontius wrote:
> > With the audio problem, my wife noticed the silent show, and I tracked
> > it back approximately to that morning's boot.
>
> Actually, when I think about it, I have just had that happen with my
> PVR350 card a week or so ago. I was very surprised on viewing a
> programme recorded earlier that day that there was no audio! I had
> just rebooted the server with the PVR card. Once I discovered the
> problem I kicked out the ivtv module (i.e. rmmod ivtv) and then
> reinstalled it (modprobe ivtv) and then sound worked again. I think
> it has happened twice over the last two or so weeks--the first time I
> have ever noticed such a problem in a number of years of using the
> card. I am running the latest kernel 2.6.34 (and prior to that I was
> sometimes running 2.6.34-rcXes since I was testing some new
> features). Maybe a problem in the kernel drivers?

The PVR-350 uses different audio decoding chips/cores than the one used
by the HVR-1600, PVR-150, and PVR-500 (which all use a CX25843 or
equivalent).

Improper functioning of an I2C connected audio decoder could be
explained by a hypothetical problem introduced in recent changes in the
linux i2c-* modules. I don't know though.

When the problem happens, the output of v4l2-ctl --log-status for the
PVR-350 should show you the state of the chips on the PVR-350. It may
be worht comparing that to when things are operating normally. You may
also want ot turn on i2c debugging with the ivtv debug module option,
and also turn on the debugging in the msp3400 module (the sound
processing chip on the PVR-350)

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


DEPontius at edgehp

Jun 12, 2010, 1:20 PM

Post #18 of 19 (2144 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On 06/12/10 08:42, Andy Walls wrote:
> On Fri, 2010-06-11 at 22:03 -0400, Dale Pontius wrote:
>> On 06/10/10 23:14, Andy Walls wrote:
>
>> Thanks for all of the thought, but last night/today/just-now I think I
>> shot any theories full of holes.
>>
>> The weather has been warming today, but last night I shut the computer
>> down. Regular shutdown, not full power-off, so 5VSB was still on, which
>> is at least significant to the red-screen. This morning, in the cold, I
>> powered on - no audio. A little later I rebooted, still no audio.
>>
>> So much for it being largely about temperature.
>>
>> It has warmed quite a bit today, and this evening I had a few minutes,
>> so I removed all of the modules, then modprobed cx18 and cx18-alsa. I
>> have sound, again.
>>
>> It's just flakey. Maybe when I get a break and take this system down, a
>> bit of dust-off and reseating cards will work wonders.
>
> Well, some things to try:
>
> 1. remove all instances of the cx18-alsa.ko module from
> under /lib/modules. It shouldn't matter, but most users never need it,
> If hald or pulseaudio has it open, you may be unable to switch away from
> 48 ksps and then back.

My kernel is getting a little long in the tooth, so it wouldn't hurt me
at some point to build a new one. 2.6.33 seemed a bit disruptive to
lirc, but I think that's worked around by now.

Do I even need cx18-alsa? I sort of built it because it was there and I
have a cx18, even though I never needed it before. What is cx18-alsa
for, anyway?
>
> 2. When you have no audio, try using v4l2-ctl to switch from the tuner
> audio to line in audio and back. You could also stop then capture,
> switch to 44.1 ksps or 32 ksps and then restart the capture.

I'll give that a shot. I've no doubt I'll get the opportunity. I'm
pleased enough that the unload/reload worked, because nothing else has
so far. I don't know if it "worked" or if it was just luck, like
booting occasionally is.
>
>
>
>> I had been focusing on initialization, partly because when we're
>> analyzing, we analyze the major modes of operation practically to death,
>> especially the performance-critical ones. There are things you can do
>> to simulate end-of-life device shifts, etc, and we do those. For the
>> power circuitry you analyze power-up to death, too. But initialization
>> is one of those typically non-critical things that you logically verify.
>
> Whenever I see
>
> Verification method: inspection
>
> in a design review, my internal alarm bells go off.

When I said "logically verify" I meant logical simulation, as opposed to
full multi-corner analog transistor-level simulation. I don't trust
"inspection" either. (There are those other phrases, "correct by
design" and "correct by construction.")

Dale

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


awalls at md

Jun 12, 2010, 6:20 PM

Post #19 of 19 (2144 views)
Permalink
Re: Sound died on hvr-1600 [In reply to]
On Sat, 2010-06-12 at 16:20 -0400, Dale Pontius wrote:
> On 06/12/10 08:42, Andy Walls wrote:

> >> It's just flakey. Maybe when I get a break and take this system down, a
> >> bit of dust-off and reseating cards will work wonders.
> >
> > Well, some things to try:
> >
> > 1. remove all instances of the cx18-alsa.ko module from
> > under /lib/modules. It shouldn't matter, but most users never need it,
> > If hald or pulseaudio has it open, you may be unable to switch away from
> > 48 ksps and then back.
>
> My kernel is getting a little long in the tooth, so it wouldn't hurt me
> at some point to build a new one. 2.6.33 seemed a bit disruptive to
> lirc, but I think that's worked around by now.
>
> Do I even need cx18-alsa?

If your only use case in MPEG TV capture/recording, then No.

If you have other use cases for capturing non-MPEG compressed audio and
video and don't mind complex and arcane command lines, then the answer
is also No.

> I sort of built it because it was there and I
> have a cx18, even though I never needed it before. What is cx18-alsa
> for, anyway?

It presents an ALSA "sound card" interface, with a control device node
and PCM capture device node, to user space for the PCM audio stream
available from the CX23418 encoder (the digital audio before the MPEG
encoder applies MPEG compression to it).

The V4L2 API provides an interface to userspace for PCM audio capture
from /dev/videoN nodes such as /dev/video24. However the
common/popular/GUI apps on linux that process or play audio normally
expect and ALSA or OSS interface, and don't know how to manipulate V4L2
controls nor look for /dev/video* device nodes for PCM audio.

The only real reason to use cx18-alsa is so that GNURadio (GNOMERadio ?)
works with an CX23418 board with FM radio. GNURadio knows to
open /dev/radio for control and expects audio to come from an ALSA PCM
device node - not /dev/video24.

Once tvtime is all fixed up, one could easily use a CX23418 board as a
dumb framegrabber, using /dev/video32 for uncompressed YUV video frames
and the ALSA device nodes for sound. That saves of the overhead of MPEG
decompression for watching Live TV. It also would be easier to play
video games through the CX23418 based card using tvtime.

Right now, if you want to hear the uncompressed audio hitting the
CX23418 encoding engine, just use

aplay -f dat < /dev/video24

while tuned to a channel (an MPEG or YUV capture need not be in
progress) and set to 48 ksps (for the -f dat parameter)

If you want to listen to FM radio on a card that supports it:

ivtv-radio -d /dev/radio0 -i /dev/video24 -f 101.5

which you will notice spawns aplay to play the audio.

Regards,
Andy

> Dale



_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users

ivtv users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.