-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/03/2012 07:38 PM, Andy Walls wrote: > On Wed, 2012-05-02 at 00:53 -0400, Bob Lightfoot wrote: >> Dear Mailing List linux-media: >> >> I am attempting to use a Hauppage HVR-1600 purchased new in 2010 >> as an analog tv tuner in my HP Pavillion Elite M9040n PC running >> Centos 6.2 x86_64. The problem I am experiencing is that with >> every kernel update and/or mythtv and/or vlc or other media >> update it seems I loose sound on my captured avi/mpeg files. >> After as bit of tweaking it seems to come back and I've never >> been able to pin down exactly what is hosing the sound. I should >> mention the unit has an HVR 1850 at slot 2 which works for DVB >> tuning jsut fine. The HVR 1600 is in pci slot 1 and from what I >> can see in dmesg it also loaded fine. Maybe someone who is more >> intimate with linux-media can review the data I've included and >> suggest a troubleshooting approach. > > 1. If you ever lose sound in the ATSC or QAM DTV streams captured > with the HVR-1600, then you do not have and HVR-1600 problem, you > have a systems sound playback problem. In this case you must > address that problem. > > If not, then go on to #2. > > 2. If you never lose sound in ATSC/QAM DTV captures, but do > sometimes lose sound with MPEG captures from the analog baseband > CVBS or S-Video w/ L and R audio inputs, then this is a driver > problem with the CX23418's audio processing unit (APU). > > In this case there is are a few things to try: > > a. prevent the cx18-alsa.ko module from loading by removing it from > your filesystem (make a back-up of the module if you wish), and > reboot your computer. This will stop things like HAL and/or > PulseAudio from messing with the HVR-1600 via the ALSA sound > interface. > > b. Update to the laters cx18 driver, which will require updating > many supporting media (video, dvb and common/tuner modules as well. > (No guarantee this will work right on older enterprise kernels > where the I2C binding model is very different from modern > kernels.) > > c. Write a patch to the cx18 driver that has it act a little > smarter about the CX23418 Capture Processing Unit (CPU) and Audio > Processing Unit (APU) initialzation. Right now the processors are > brought out of reset and allowed to run executing uninitialized > memory as instructions before their firmware is actually loaded and > the processors restarted. > > d. Ask me to write the patch mentioned in c. Be prepared to wait a > very long time and still have to update to the latest cx18 module. > > > If you never lose audip in MPEG captures from baseband inputs, then > go to step 3. > > 3. If you never lose sound in ATSC/QAM DTV captures, and never > lose sound with MPEG captures from the analog baseband CVBS or > S-Video w/ L and R audio inputs, but you do sometimes lose audio > with MPEG captures from the analog RF tuner, then the broadcast > audio microcontroller in the integrated CX25843 inside the CX23418 > is likely unable to identify the broadcast audio standard properly > and is staying muted. > > If so, then > > a. Use 'v4l2-ctl -d /dev/videoN --log-status' to verify the audio > standard is not detected and the microcontroller is muted when an > analog RF capture is ongoing. > > b. Try installing an in-line attenuator in the RF line before it > reaches the analog RF tuner input of the HVR-1600. The audio > microcontroller uses spectral analysis hardware to detect the > broadcast audio standard. Intermodulation products, caused by > overdriving the tuner with too strong of a signal, can throw off > the spectral analysis and confuse the audio standard detection > microcontroller. > > c. Ask Mark Lord for a copy of his script/tool mentioned in this > long thread: http://patchwork.linuxtv.org/patch/3162/ That > periodically does some userspace actions to try and get audio > back. > > d. Write a patch to the cx18 driver and the cx18-av-*c files > specifically, that allows manual specification of audio standard to > BTSC without any attaempts at auto-detection. > > e. Ask me to write the patch in d. Be prepared to wait a long > time, etc. etc. > > f. See 2.c. > > g. See 2.d. > > > >> I am beginning to suspect I need to specify a conf file for >> module cx18 but not sure where to begin that. I am trying to >> maintain the package management on this system so I have not >> isntalled sources or compiled anything, everything has been >> managed by yum and pulled from the centos-base, centos-updates or >> atrpms repos for 99% of things. There may be an elrepo or >> rpmfusion rpm or two, but they would be an exception. Below I am >> providing what I think is the relevant starter information. >> >> >> uname -a ==> Linux mythbox.ladodomain 2.6.32-220.13.1.el6.x86_64 >> #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 >> GNU/Linux >> >> lspci output follows: >> >> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express >> DRAM Controller (rev 02) 00:01.0 PCI bridge: Intel Corporation >> 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02) 00:19.0 >> Ethernet controller: Intel Corporation 82566DC-2 Gigabit Network >> Connection (rev 02) 00:1a.0 USB controller: Intel Corporation >> 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB >> controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >> Controller #5 (rev 02) 00:1a.7 USB controller: Intel Corporation >> 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 >> Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio >> Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801I >> (ICH9 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: >> Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev >> 02) 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 >> Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: >> Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 >> (rev 02) 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 >> Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: >> Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 >> (rev 02) 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 >> Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: >> Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: >> Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev >> 02) 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH >> (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] (rev 02) 00:1f.3 >> SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller >> (rev 02) 00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 >> Family) 2 port SATA Controller [IDE mode] (rev 02) 01:00.0 >> Multimedia video controller: Conexant Systems, Inc. CX23418 >> Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast >> Audio Decoder 01:05.0 FireWire (IEEE 1394): Agere Systems >> FW322/323 (rev 70) 02:00.0 Multimedia video controller: Conexant >> Systems, Inc. CX23887/8 PCIe Broadcast Audio and Video Decoder >> with 3D Comb (rev 0f) 04:00.0 VGA compatible controller: nVidia >> Corporation G98 [GeForce 8400 GS] (rev a1) >> >> Output from dmesg | grep -A 3 -B 3 cx18 --> follows below: >> SELinux: initialized (dev mqueue, type mqueue), uses transition >> SIDs lo: Disabled Privacy Extensions SELinux: initialized (dev >> proc, type proc), uses genfs_contexts cx18: Start >> initialization, version 1.5.1 cx18-0: Initializing card 0 cx18-0: >> Autodetected Hauppauge card cx18 0000:01:00.0: PCI INT A -> GSI >> 17 (level, low) -> IRQ 17 cx18-0: cx23418 revision 01010000 (B) >> tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# >> 5267091 tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93 >> tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type >> 50) -- 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-0: >> Autodetected Hauppauge HVR-1600 cx18-0: Simultaneous Digital and >> Analog TV capture supported IRQ 17/cx18-0: IRQF_DISABLED is not >> guaranteed on shared IRQs tuner 5-0061: Tuner -1 found with >> type(s) Radio TV. cs5345 4-004c: chip found @ 0x98 (cx18 i2c >> driver #0-0) tuner-simple 5-0061: creating new instance >> tuner-simple 5-0061: type set to 50 (TCL 2002N) cx18-0: >> Registered device video2 for encoder MPEG (64 x 32.00 kB) DVB: >> registering new adapter (cx18) cx18 0000:01:00.0: firmware: >> requesting v4l-cx23418-cpu.fw MXL5005S: Attached at address 0x63 >> DVB: registering adapter 1 frontend 0 (Samsung S5H1409 QAM/8VSB >> Frontend)... cx18-0: DVB Frontend registered cx18-0: Registered >> DVB adapter1 for TS (32 x 32.00 kB) cx18-0: Registered device >> video34 for encoder YUV (20 x 101.25 kB) cx18-0: Registered >> device vbi2 for encoder VBI (20 x 51984 bytes) cx18-0: Registered >> device video26 for encoder PCM audio (256 x 4.00 kB) cx18-0: >> Initialized card: Hauppauge HVR-1600 cx18: End initialization >> cx18-alsa: module loading... cx18-0: loaded v4l-cx23418-cpu.fw >> firmware (158332 bytes) cx18 0000:01:00.0: firmware: requesting >> v4l-cx23418-apu.fw cx18-0: loaded v4l-cx23418-apu.fw firmware >> V00120000 (141200 bytes) cx18-0: FW version: 0.0.74.0 (Release >> 2007/03/12) cx18 0000:01:00.0: firmware: requesting >> v4l-cx23418-cpu.fw cx18 0000:01:00.0: firmware: requesting >> v4l-cx23418-apu.fw cx18 0000:01:00.0: firmware: requesting >> v4l-cx23418-dig.fw cx18-0 843: loaded v4l-cx23418-dig.fw firmware >> (16382 bytes) cx18-0 843: verified load of v4l-cx23418-dig.fw >> firmware (16382 bytes) readahead-collector: starting delayed >> service auditd readahead-collector: sorting readahead-collector: >> finished -- > > >> hda-intel: Invalid position buffer, using LPIB read method >> instead. hda-intel: IRQ timing workaround is activated for card >> #0. Suggest a bigger bdl_pos_adj. > > That's your audio chipset driver blurting out that something isn't > right. You should investigate that too. > > > > >> >> I'll end here and hope for someone to have an idea as I've about >> exhausted my brain on this. > > Hopefully I gave you enough to work with for a while. > > Regards, Andy > >> Sincerely, Bob Lightfoot > > Andy - WOW - talk about spot on help thanks a ton. 1. I think item 1 can be ruled out as I've never had an issue with sound on DTV. Except as you say when I lost it on both my hvr1600 and hvr1850 and pulseaudio was mucking stuff up. 2. Item 2 will take a day or two to verify the s Video with L/R Audio as those are not presently connected to a source. but based on my web search and what you mention about item 3 I suspect that is my issue. 3. I am able to use the v4l2-ctl command and confirm that audio standard is not detected and audio is muted. NOTE: I made a follow up post about this a day or two ago IIRC. The attenuator makes some sense. I also noticed that the video is showing ground loop lines on occaision so I'll recheck the coax between the hvr1600 and the Satellite Reciever generating the analog signal. More to come, but you've done a bunch for which I am thankful at this point. Don't know how I'll return the favor one day, but will try. Bob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPo3+sAAoJEKqgpLIhfz3XY3YH/RAoNk3XLF8iq7ceI1alUk7p vAeYwU75/5VycZkmMDQFGTNzriqsL10sj4gNKSCyrjFiWfaazPAEMT4od8MX2QR3 /suvYmTpyNd1G5L386EAKghkh/d6Z9anmpfEZFXSX2bi9KegW/lvr86oOkjoCjSk DPbHeUYsAUTnA0+XJd+bHyK77yfD4cXHyh1XPi36DJcXXUtQu0kOlsLCrD1EaqMJ z/+hjyn40+ULU1euyFZ4oRt2yBQ2JxWTKjUbhbihCxhEsYuPuTnYFJhA99ijVJF3 wBgQHQBVKw9sNH/Ash/MxAij56ETlaxwarCLhTMUMnN+WHKq7+6PijGdZcXuDGo= =GQpn -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
