On Sun, 2009-04-12 at 21:04 -0400, Jeff Campbell wrote: > Hi Andy, > > I'm in the process of packing up and moving house at the moment, > should be resettled some time at the beginning of July. > > Unfortunately, my test units are going to be packed away soon. > > I am moving from a non-ATSC area in to an ATSC available area. I was > wondering if you might be able to provide a summary of the current > ATSC support in the chip.
ATSC and North American QAM works for the HVR-1600. Support for digital TV for other cards could be added given sufficient information. All other CX23418 based cards I know of are DVB-T. > A few questions about it. > > -Is the configuration process as simple as scanning for channels and > then selecting one via a v4l-ctl (if working from the command line)? No. You've got to build a scan file for your cable provider or OTA locality. For OTA ATSC on Fedora, I use this: $ scandvb -A 1 -v -a 0 /usr/share/dvb-apps/atsc/us-ATSC-center-frequencies-8VSB > channels.conf Note, Fedora renamed the scan command. Note you also need a file list with frequencies to scan (which should come with your scan command app). > -Is the simultaneous capture from the analog input and the ATSC input > working in a stable fashion? Yes. > -What is the highest bitrate you have seen on the ATSC input? ATSC has a fixed bitrate overall: ~19.(mumble) Mbps. The resolution of the programs on the multiplex depends on how much the broadcaster wants to stuff in that 19.x Mbps. > -Are you aware of any problems with 2 x analog + 2 x ATSC capture on > the same PCI bus? No. It should work, but I have never tried it. Brandon Jenkins on the LMML has 3 HVR-1600s in a box. I have a set of "performance" improvement patches in the works for the cx18 driver that I'll be pushing out soon. They remove all sleeps (schedule()'s due to mutex_lock() acquisition delays or wait_event()'s for ack IRQ's from the firmware) on the applications' read() paths or when shuffling incoming buffers around. I also created more granular queue locks for higher concurrency. Those all certainly improve single card live playback performance. I'm not sure how well it will scale, before it will fallback to wait_event()'s in the applications' read() paths or when shuffling incoming buffers. But it does gracefully fallback. > -Any antennas you have had particularly good luck with (or anyone else > who wants to chime in)? In the US, most stations are digital on UHF freq's. Once the DTV cutover is complete, some stations will migrate back to their VHF assignments. Basically a good VHF/UHF antenna for your needs. If you're close in, an omni, or small directional, that you can easily rotate, will be fine. Farther out, you'll want one with higher directivity. Good cables: RG-6/U quad-shield. Good grounding of the coax shield near the antenna to earth ground, to reduce EMI and provide some lightning protection. Proper splitters and terminators everywhere in your distribution plant. A VHF/UHF amp from Winegard. Not more gain than you need though. Too much gain and you'll overdrive the front end of your tuners, creating intermodulation products and essentially raising your noise floor. Keep the antenna far away from any source of VHF/UHF EMI from home electronics. PC's have square waves that have fundamentals and harmonics that land right in UHF. > -Is there any support for breaking out guide data that may be in the > ATSC TS? MythTV can do it. > -Any other things a new user might benefit from? dvbsnoop is somewhat interesting, but is limited in decoding a TS in places. femon is useful. dvbtraffic may be useful to you. > Thanks again for all your work on the driver. You're welcome. > We have a patch we hope to give you soon around the volume level > calculations for the RF input, we think we found a math bug there. Hmm. I went though them once and found they were OK. (My wife just helped me find my notes.) I have these equations scrawled down: V = (((114 * 2) - r) / 2 + (-96 - -114 + 1) + 4) * 512 r = -((V / 512 - (-96 - -114 + 1) - 4) * 2 - (2 * 114)) Which IIRC converts between the volume control value to the register value. The 9 LSBits of the V4L2 volume control are ignored/insignificant when setting the CX23418 volume: that's the 512. I recognize the 4 dB fudge factor. -96 dB is the low end of the CX23418 audio vol control -114 dB is the low end of the MSP3400 vol control 18 dB is the high end of the CX23418 audio vol control, so that's 18 - -96 = 114, 1 dB steps or 228, 1/2 dB steps (of course the 0 dB value seems to have been forgotten in that calculation, I'll have to double check those steps.) Bah, I'll have to double check it all.... > Also, we're still searching for an indication in the docs that the > audio path on the SA input should be able to be volume controlled. > Thinking it through it seems like it would be but we've seen no sign > of it so far. Perhaps it is meant to be line level locked? The last idea I had was that it was hard-routed through path 2 of the baseband processing. Experimentation revealed to me, that this was not the case. I'm pretty much resigned to setting up the CS5345 to do the volume control for line-in. I just need to get it done. Regards, Andy > > -Jeff _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
