Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/10/2009 10:32 AM, Steven Toth wrote: David Ward wrote: Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB). I looked afterwards and saw that the first of those is analog programming, but the second just appears as analog noise on my TV set. (??) I asked them to check a specific ATSC channel, but it seems that their meter was fixed to those two frequencies, which doesn't really help. The ATSC rebroadcasts by Comcast are on high frequencies; the program I am testing primarily is on channel 79 (tunes at 555 MHz). I need to make a correction here. I am receiving all programming over digital cable. I mistakenly thought that rebroadcasts of over-the-air signals on a cable network followed all the ATSC specifications (including the modulation scheme) over the particular carrier frequency. Now I understand that like all other digital cable channels, local channels are broadcasted using QAM rather than 8VSB (but then they also include PSIP data as required by the FCC). So the SNR requirements for QAM-256 are the ones that should apply to my situation. That's a big misunderstanding on my part...my bad. Which of these three values is UNC/BER and which is snr? I don't understand, I need you to be more specific. Sorry for not being clear. I tested again thoroughly under both Linux and Windows before writing this response. Linux is tuning almost all channels at a SNR approximately 3 dB less than under Windows. That is why I now believe this is a tuner driver problem. I composed a table for myself with average SNRs per channel while running both Windows and Linux to determine this, both with the tuner card connected directly to the household cable, and connected behind the splitter in my house. Under Windows, channels with low frequencies have an SNR of ~35 dB, and channels with high frequency have an SNR of ~33 dB, when connected directly to the household input. The splitter at most gives me a loss of 1 dB but often makes no difference. Again, sorry for not making that clear. I think the 3 dB difference is the real issue at play here, and is the reason I'm writing this message to this list, rather than one intended for household wiring issues. Did you get a chance to review the signal monitor to determine whether it was 64 or 256? All channels are 256-QAM -- reported as such by both Linux and Windows. If you have any way to attenuate the signal then you'll find that very quickly the windows 30.5 will drop just a little and you'll begin to see real uncorrectable errors. I alluded to this yesterday. With 30.5 your just a fraction above 'working' reliably. If you were to insert attenuation through some barrel connectors, or join some other cables together to impede the RF, you'd see that 30.5 drop quickly and the errors would begin to appear. I suspect this will still occur, as I mentioned yesterday. The windows drivers is working slightly better for you but it's still no where near good enough RF for reliable 24x7x365 viewing. You'll find the RF on your local cable rings varies during an average day. It certainly does for me on various products. What looks great today (when you're on the edge) can look ugly at 9pm in the evening or 7am thursday morning. I wouldn't expect pristine recordings with Microsoft MCE (or other apps) (for any random moment in the week) with a 30.5 reading. Based on our discussion until now, the difference between 30.5 dB and 33.5 dB should be very significant, and I hope would warrant an investigation into the cause (possibly asking Hauppauge/Conexant to compare details of your tuner drivers against theirs? I understand they provide support to the Linux community). As you said, if Windows was only picking up the channels at 30.5 dB, then I shouldn't expect much more than I am getting now, as I would be riding on a thin line between errors and no errors. Sorry for not being accurate in some of my earlier messages, and thanks for being patient with me. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 03:26 PM, Steven Toth wrote: 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? Steven and Devin, All the digital signals are 256 QAM. 39 is very good, exceptional. And did they do as I suggested, which is measure db across the high channels? ... and ideally against your problematic channel? I assume not. Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB). I looked afterwards and saw that the first of those is analog programming, but the second just appears as analog noise on my TV set. (??) I asked them to check a specific ATSC channel, but it seems that their meter was fixed to those two frequencies, which doesn't really help. The ATSC rebroadcasts by Comcast are on high frequencies; the program I am testing primarily is on channel 79 (tunes at 555 MHz). Under Windows I'm now seeing 34.5-34.8 dB for lower frequency QAM, 32.5-32.7 dB for higher frequency QAM, and about 30.5 dB for ATSC. Under Linux with azap, the corresponding BER/UNC values are 0x0140, 0x0134, and 0x0132. I'm not exactly sure what numbers I should be going by here...again, wish I had my own meter. I admit that I ruled out the idea of RF issues too soon, which I really should know better than. After reading the thread at http://forums.gbpvr.com/showthread.php?t=36049 I'm now realizing why reception on the TV and tuner card isn't going to be equal, due to limited size and shielding of tuner circuitry on a PCI form factor card vs. on a TV set. Makes sense. Still, I am continuing to see uncorrectable bit errors at the same rate as before under Linux, while Windows sees errors but corrects them. I would think that both drivers should be receiving identical streams of data from the chipset, and should be able to process them the same way? That's what is confusing me. Ideally I would like to have access to a lot more equipment to control all the variables and make it easier to reproduce what I am seeing...but I don't here... Or do you guys think that this is still primarily an RF problem? I don't know what else I could do about that though. Since the SNR did not improve when I hooked the tuner card directly into the cable input from the street, I'm concerned that putting an amplifier would not help and could just make things worse. And clearly Comcast now considers me to be within their quality thresholds. I really appreciate your help and patience with me, especially to the extent that this is going outside the realm of DVB drivers. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/09/2009 03:26 PM, Steven Toth wrote: 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? Steven and Devin, All the digital signals are 256 QAM. 39 is very good, exceptional. And did they do as I suggested, which is measure db across the high channels? ... and ideally against your problematic channel? I assume not. Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB). I looked afterwards and saw that the first of those is analog programming, but the second just appears as analog noise on my TV set. (??) I asked them to check a specific ATSC channel, but it seems that their meter was fixed to those two frequencies, which doesn't really help. The ATSC rebroadcasts by Comcast are on high frequencies; the program I am testing primarily is on channel 79 (tunes at 555 MHz). Under Windows I'm now seeing 34.5-34.8 dB for lower frequency QAM, 32.5-32.7 dB for higher frequency QAM, and about 30.5 dB for ATSC. Under Linux with azap, the corresponding BER/UNC values are 0x0140, 0x0134, and 0x0132. I'm not exactly sure what numbers I should be going by here...again, wish I had my own meter. Which of these three values is UNC/BER and which is snr? I don't understand, I need you to be more specific. 34 is good, normal. However 30.5 is still edgy under windows, assuming QAM 256. Did you get a chance to review the signal monitor to determine whether it was 64 or 256? If you have any way to attenuate the signal then you'll find that very quickly the windows 30.5 will drop just a little and you'll begin to see real uncorrectable errors. I alluded to this yesterday. With 30.5 your just a fraction above 'working' reliably. If you were to insert attenuation through some barrel connectors, or join some other cables together to impede the RF, you'd see that 30.5 drop quickly and the errors would begin to appear. I suspect this will still occur, as I mentioned yesterday. The windows drivers is working slightly better for you but it's still no where near good enough RF for reliable 24x7x365 viewing. You'll find the RF on your local cable rings varies during an average day. It certainly does for me on various products. What looks great today (when you're on the edge) can look ugly at 9pm in the evening or 7am thursday morning. I wouldn't expect pristine recordings with Microsoft MCE (or other apps) (for any random moment in the week) with a 30.5 reading. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Thanks. I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Tothst...@kernellabs.com wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. 33 should be fine for any Linux TV device. Make sure the engineer checks for 33db across a range of the higher (80 thru 100) rf channels (where rf falloff of common). Let us know how you get on. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth st...@kernellabs.com wrote: I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com I agree it's high, but certainly possible. I've got a 30 dB signal, but my situation is a bit unusual. I spent all of last night working on another issue, but I am hoping to get back to it this week. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 2:52 PM, David Ward david.w...@gatech.edu wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 2:52 PM, David Ward david.w...@gatech.edu wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. Devin 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth st...@kernellabs.com wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth st...@kernellabs.com wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? Devin 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx18, s5h1409: chronic bit errors, only under Linux
I have a Hauppauge WinTV-HVR-1600 that I am using to capture ATSC and clear QAM programming from cable television (Comcast of Chattanooga). This card uses the cx18 and s5h1409 kernel modules. There are frequent bursts of bit errors occurring every few seconds in the incoming transport stream, when I have the card tuned under Linux. This causes artifacts in the received video as well as skipping in the received audio, to the point that it is practically unwatchable. However, under Windows on the same system/capture card, I can tune to the same programs with nearly perfect reception (no bit errors). Also these programs appear on my TV with great quality as well. The problem is happening on all of several different frequencies/programs that I have tried, although it is more pronounced on some programs (particularly ATSC) than others. I have tried the latest v4l-dvb development sources under both kernel 2.6.24 and kernel 2.6.29, and additionally I have tried to use the unmodified v4l-dvb from kernel 2.6.29. Additionally, I have tried both the recommended cx23418 firmware from linuxtv.org, as well as the newer firmware provided by latest the Hauppauge drivers for Windows (which I am using successfully under Windows). Unfortunately they all produce the same results. I primarily use MythTV to capture the programs to a file, and the resulting file exhibits these problems. However, I can also see the bit errors when I simply use the 'azap' application to tune the card directly (and also read the dvr0 device into a file). The BER and UNC values reported by 'azap' are non-zero approximately one out of every five samples; then they are usually around 0x200, though this varies. The BER and UNC values are almost always identical, i.e., no error correction is taking place, only error detection. Additionally I am not seeing any TS continuity or TEI flag errors, as detectable in the system log with the latest changeset. I have tried to rule out other possible causes such as a weak input signal (by hooking the capture card directly to the household cable television input, bypassing all coaxial splitters) and system-specific issues (by trying this on three different systems). However, to me it seems that the problem must be originating from an issue in the kernel modules for this card. I understand that having some errors in the transport stream is unavoidable, and I have tried postprocessing with an application such as Project-X. However, it does not magically take care of this -- the length of the video is reduced by about 20% and the resulting video jumps around constantly. Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. Thanks, David Ward -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth st...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 10:17 AM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 10:14 AM, Steven Tothst...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin Steven, Devin, Thanks for your replies. The signal and SNR are usually in the range 0x0128 - 0x0140. They may increment or decrement on a per-second basis but otherwise remain steady. The status field does not change most of the time when bit errors occur, but it does lose the lock from time to time for a second. Here is a representative sample: da...@delldimension:~$ azap -r RTN using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x0051, audio pid 0x0052 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 012e | snr 012e | ber 1b04 | unc 1b04 | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0269 | unc 0269 | FE_HAS_LOCK status 1f | signal 012e | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0266 | unc 0266 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0002 | unc 0002 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0150 | unc 0150 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0273 | unc 0273 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0001 | unc 0001 | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 07 | signal 012c | snr 012c | ber | unc | status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber 0263 | unc 0263 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 10:17 AM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 10:14 AM, Steven Tothst...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin Steven, Devin, Thanks for your replies. The signal and SNR are usually in the range 0x0128 - 0x0140. They may increment or decrement on a per-second basis but otherwise remain steady. The status field does not change most of the time when bit errors occur, but it does lose the lock from time to time for a second. Here is a representative sample: da...@delldimension:~$ azap -r RTN using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x0051, audio pid 0x0052 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 012e | snr 012e | ber 1b04 | unc 1b04 | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 12:31 PM, Steven Toth wrote: Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. Oh okay ... I wasn't sure how to translate those values before. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. In your opinion, would I have enough justification for asking Comcast to increase the signal strength coming to my house? I'd like to avoid calling someone to come out to my house to say your TV works fine, what's the problem? and get slapped with a repair fee. I wasn't sure how well I could trust the SNR values reported by the card either... I wish I had a meter or something to test it on my own. When I move the computer directly to the input for the entire house, I get an increase of about 0.1dB. FYI, the signal strength is about 1dB higher for clear QAM signals. (The values I sent are for ATSC.) It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. I tuned to the same channel under Windows, and I used the Signal Strength Indicator application from Hauppauge (downloadable under the Accessories page in the Support section). It's reporting a SNR of 29-30 dB, and the value for 'correctable' errors goes to a single-digit value about every 5 seconds -- following the same pattern seen with 'azap'. However, the difference is that 'uncorrectable' errors stays at 0. Under Linux, it seems that all errors are 'uncorrectable'. Does the error correction occur in the driver or in the chipset? Seems to me like maybe error correction is either not enabled or not implemented correctly by the driver? I agree that the SNR could be better, and if you think it is worth a try, I'll see what Comcast will do. However, because Windows and my TV work almost flawlessly, the Linux driver would ideally handle the signals at least as well as them... Let me know what else is helpful from me, and thanks again for your help. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 12:31 PM, Steven Toth wrote: Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. Oh okay ... I wasn't sure how to translate those values before. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. In your opinion, would I have enough justification for asking Comcast to increase the signal strength coming to my house? I'd like to avoid calling someone to come out to my house to say your TV works fine, what's the problem? and get slapped with a repair fee. I wasn't sure how well I could trust the SNR values reported by the card either... I wish I had a meter or something to test it on my own. When I move the computer directly to the input for the entire house, I get an increase of about 0.1dB. No idea, I debug my own cable network issues. That being said, usually cable companies like to deliver 0db to the house which is nice and hot, then it gets split and energy loss occurs 9as well as noise injection). I usually take home some metering equipment from the office to sweep my home network. FYI, the signal strength is about 1dB higher for clear QAM signals. (The values I sent are for ATSC.) It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. I tuned to the same channel under Windows, and I used the Signal Strength Indicator application from Hauppauge (downloadable under the Accessories page in the Support section). It's reporting a SNR of 29-30 dB, and the value for 'correctable' errors goes to a single-digit value about every 5 seconds -- following the same pattern seen with 'azap'. However, the difference is that 'uncorrectable' errors stays at 0. Under Linux, it seems that all errors are 'uncorrectable'. So you don't have much leg room with windows either, certainly not enough for my liking. The difference between zero errors and a small handful can be pretty small in RF terms. Does the error correction occur in the driver or in the chipset? Seems to me like maybe error correction is either not enabled or not implemented correctly by the driver? Error recovery is done in the chipset and is only as good as the RF signal reaching the demodulator. I agree that the SNR could be better, and if you think it is worth a try, I'll see what Comcast will do. However, because Windows and my TV work almost flawlessly, the Linux driver would ideally handle the signals at least as well as them... No idea and no I don't agree, just because your TV works doesn't mean the Linux driver has to be reliable. That's wishful thinking on your part and Comcast are not obliged to make your TV tuner work. Again, if you have 29-30db on Windows you don't have a lot of legroom for signal attenuation before you'll see errors. I frequently had windows reception errors when running at 31db with some boards. We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Is the mxl5005s Linux tuner driver perfect? Is it as good as windows? Not quite, but it's good for many people and it's unlikely to improve in the near future. Try installing a decent cable amp. Try looking at the MythTV wiki and support sites for improving your cable network. Let me know what else is helpful from me, and thanks again for your help. David No problem, your welcome. I hope this advice helps. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Tothst...@kernellabs.com wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I am actually comparing the TS files captured under both Linux and Windows side-by-side in the same environment, copying the files to other computers in my home. I can demux the video with Project-X which prints out the errors in the bitstream as it reads them. I can also observe the overall quality by playing it back with VLC, WinDVD, etc. When I use TMPGEnc Authoring Works 4 to read the file, the errors in the bitstream even seem to crash the application -- though obviously TMPGEnc is to blame for that. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 5:03 PM, David Ward david.w...@gatech.edu wrote: Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. Well, I've got a few different combinations of s5h1409 tuners and demods (including the HVR-1600), so if I can reproduce the issue, I can probably narrow it down as to whether it's a tuner or a demod issue. I've spent a good bit of time analyzing the s5h1409 driver in the past, although I don't have the datasheet for the chip. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, 2009-06-08 at 16:20 -0400, Steven Toth wrote: Try installing a decent cable amp. Try looking at the MythTV wiki and support sites for improving your cable network. If using an amp, be sure you pick one with appropriate gain and noise figure. Overdriving the mxl5005s with too much signal can degrade SNR as well. Here's my standard list of things to check: http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality Good luck. Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
