Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Processor causing A52 CRC Errors Goto page Previous  1, 2, 3  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Mon Apr 17, 2006 7:23 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
Didn't we also determine that the DVB driver isn't logging buffer overflows?

I modified the driver to help debug the problem of course. I'm not having a problem with the dvr buffer, the cx88 DMA buffers, or the cx88's internal SRAM fifo overflowing. I thought that's where the problem would be, but it's not. The cx88 thinks it's getting bad data from the demodulator. Does the demodulator think it's providing bad data? I don't know, that's the one part I don't have specs for. I suspect RF interference or noise in the power supply is causing a problem either with the demodulator or the demod -> cx88 channel.

The analog demodulator is inside the tuner 'tin can', to protect it from EMI. The newer generator of digital tuners, like the LGDT3303 that will be in the upcoming pcHDTV HD-5500 card, have the digital demodulator inside the can too. The HD-3000's demodulator isn't EMI shielded, so maybe that's the problem.
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 10:34 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




What code did you change in the driver? Did you fix the missing overrun message? Can you post a diff and the output it produces so we can compare it to other boards?

Perhaps you simply have a defective board since many more people are getting great results with the HD-3000, whatever its specifications may be.
View user's profile Send private message
PostPosted: Thu Apr 20, 2006 3:48 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
What code did you change in the driver? Did you fix the missing overrun message? Can you post a diff and the output it produces so we can compare it to other boards?

Perhaps you simply have a defective board since many more people are getting great results with the HD-3000, whatever its specifications may be.


I didn't bother to save my changes so I on longer have a patch. A check for the dvr buffer overflow is still there, it just not turned on unless you turn on debugging. See dvb_dmxdev_buffer_write() in dmxdev.c. To check for FIFO overflows and bad packets, I turned on those bits in cx8802_start_dma() in cx88-mpeg.c. You need to enable the bits in the interrupt mask and turn the abilities on in their individual control registers, like TS_FIFO_OVFL_STAT. Then in the mpeg irq handler, check the error bits and if set print an error and get the error count. To check for running out of DMA buffers, check for the empty list condition in cx88_wakeup().

Didn't you say your HD-3000 drops packets if you move your mouse? I wouldn't call that working correctly. I can move my mouse, it's only certain X activity with the nvidia driver (vs the nv driver) that kills it.
View user's profile Send private message
PostPosted: Thu Apr 20, 2006 9:02 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




How about getting the original driver source and posting diffs against that? For all we know you may have broken something in your version of the driver. I strongly believe at this point that you simply have a defective board.

I didn't say I can cause buffer overflows by moving my mouse. I can cause xine and mplayer to drop frames when playing HDTV when moving the mouse around for several seconds because they get stuck waiting for the X lock to be released. The frames aren't displayed but no data is lost.
View user's profile Send private message
PostPosted: Thu Apr 20, 2006 11:57 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
How about getting the original driver source and posting diffs against that? For all we know you may have broken something in your version of the driver. I strongly believe at this point that you simply have a defective board.


I guess I wasn't clear, I'm not using a modified driver anymore. At least not significantly. What I did to narrow down my loss problems was just a quick hack and not something I intended to continue to use. I reverted my source so I would have a clean tree to submit patches to linuxtv from. The problem hasn't changed from the stock 2.6.12 driver to the latest linuxtv Hg sources to what I'm using now. Defective board, maybe. I still see a lot of other people with problems.
View user's profile Send private message
PostPosted: Thu Apr 20, 2006 3:38 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




People who have reception problems only during X activity? Maybe they have defective boards too. Maybe defective motherboards. Maybe defective videocards.

From what I can tell, the driver will simply report "bad data" when it receives bad data. That can be caused by any kind of interference.
View user's profile Send private message
PostPosted: Thu Apr 20, 2006 9:15 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
People who have reception problems only during X activity? Maybe they have defective boards too. Maybe defective motherboards. Maybe defective videocards.

Maybe they don't put as much effort into trying to solve the problem as I do? Most people just say, "I get A52 errors with mplayer," and then give up. Those bugs in mplayer's TS demuxer that could cause A52 errors were probably around for years before I fixed them. Same with the HD-3000 driver using the wrong tuner, it was like that since the card was released, but nobody before me bothered to check. How many people have reception problems that might be caused by EMI from their videocard, but they never narrow it down?
Quote:

From what I can tell, the driver will simply report "bad data" when it receives bad data. That can be caused by any kind of interference.

The DVB driver has no mechanism to report "bad data". The only thing close is the transport error bit in the TS packet header, and that's inserted by the demodulator, not the driver. If the cx23880's MPEG port doesn't like what it's getting from the demodulator, it just drops the data. The current driver disables all the cx88's error indicators and has no clue anything is wrong.
View user's profile Send private message
PostPosted: Fri Apr 21, 2006 12:50 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Have you narrowed it down? How can you tell the difference between a strong signal that's being interfered with and a plain old weak signal? And how do you know if your board is defective?

I only got the A52 errors during the week I used it with cable. I never got them in any other case so apparently not many people were having the problem. And if my HD-3000 was using the wrong tuner, it was doing a damn fine job with it.

I use the old pcHDTV drivers that have no concept of MPEG so maybe it doesn't use the "MPEG port". I can't justify all the problems with the DVB driver not reporting errors and I agree it should report any errors it finds.
View user's profile Send private message
PostPosted: Fri Apr 21, 2006 5:58 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
Have you narrowed it down? How can you tell the difference between a strong signal that's being interfered with and a plain old weak signal? And how do you know if your board is defective?

How could I get a weak signal that only appears every time there is X activity with the nvidia driver? It's obvious that the problem is caused by X somehow. You think it's a coincidence when I move a window, the packets start getting dropped? And when it happens every single time I move a window, it's just the same conincidence over and over and over again? That's absurd.
Quote:

I only got the A52 errors during the week I used it with cable.

Well there you go. Cable is around double the bandwidth of OTA and needs a cleaner signal. Maybe if you were using cable you would have the exact same problem.
Quote:

And if my HD-3000 was using the wrong tuner, it was doing a damn fine job with it.

It only made a difference with cable, and then only on a couple of analog channels. But you say you only used cable for a week, so you probably didn't notice.
Quote:

I use the old pcHDTV drivers that have no concept of MPEG
so maybe it doesn't use the "MPEG port".

The mpeg port is function 2 of the cx23883 chip, it is used to communicate with the demodulator. It's not something the driver can not use. Run lspci, you'll see it listed.
Code:

00:0d.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
00:0d.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
View user's profile Send private message
PostPosted: Sat Apr 22, 2006 2:41 pm Reply with quote
theyneverknew
 
Joined: 19 Apr 2006
Posts: 12




I believe I'm having the same or at least a very similar issue. It also seems to be the same as the issue mentioned in several threads about playing teh stream causing FE_HAS_LOCK to be lost. I'm recording off of cable using QAM_256 and everything works perfectly if i record the stream and then play it back later. When I try and play a stream as it is recording then it will be garbled from the point I started playing it onwards.

After seeing this thread I checked to see if it was just X activity that could be the problem and it seems that it is. I ran azap in one terminal, then switched over to X and ran mplayer /dev/dvb/adapter0/dvr0. As with before this led to a corrupted picture and messed up audio. However when I left mplayer running but switched to the console with azap running the audio became perfectly clear and azap regained FE_HAS_LOCK.

I've also noticed that streams will record with lots of errors if I am trying to watch any other video while it is recording. Initially I thought it might be a problem with disk bandwidth, but watching videos off of a network share also screwed up the recording.
View user's profile Send private message
PostPosted: Mon Apr 24, 2006 6:23 pm Reply with quote
theyneverknew
 
Joined: 19 Apr 2006
Posts: 12




Working off a hunch from reading through this thread I am now fairly certain that local video playback is somehow the cause of these signal problems. I installed mythfrontend on my laptop, and I am able to watch live tv with perfect reception when I play it on my laptop, but if I try to do it on the machine that the pcHDTV card is in the same signal issues are still there.
View user's profile Send private message
PostPosted: Mon Apr 24, 2006 6:46 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
The mpeg port is function 2 of the cx23883 chip, it is used to communicate with the demodulator. It's not something the driver can not use. Run lspci, you'll see it listed.
Code:

00:0d.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
00:0d.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)

Of course how lspci describes devices is arbitrary.
Code:
00:13.0 Multimedia video controller: Conexant: Unknown device 8800 (rev 05)
00:13.2 Multimedia controller: Conexant: Unknown device 8802 (rev 05)

I don't see anything in the pcHDTV (ATSC) driver that claims to be an "MPEG Port". There is a "serial data" port. I guess the driver doesn't care if it's getting MPEG data out of it.

Now how do you know you weren't getting buffer overflows again? I know you've said over and over and over and over that you weren't getting buffer overflows but if you're dealing with QAM 256 then you have twice the amount of data coming in and you're twice as likely to overflow the buffer if a greedy video driver is hogging the kernel.

It sure would have been helpful if you had kept all the changes you made to the driver to find these things out. People could have used them to debug their own problems and perhaps tell you if you have a defective board.
View user's profile Send private message
PostPosted: Mon Apr 24, 2006 6:52 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




theyneverknew wrote:
I've also noticed that streams will record with lots of errors if I am trying to watch any other video while it is recording. Initially I thought it might be a problem with disk bandwidth, but watching videos off of a network share also screwed up the recording.

Here's another experiment: when recording a show, copy some large files and see if that corrupts the recording. You can also test with some other non-video system activity like recompiling the kernel and see if that causes corruption.
View user's profile Send private message
PostPosted: Mon Apr 24, 2006 9:22 pm Reply with quote
theyneverknew
 
Joined: 19 Apr 2006
Posts: 12




I just tried recording while copying a large file and while compiling the kernel and the recordings turn out perfectly fine. There is definitely some interaction between video playback and signal problems.
View user's profile Send private message
PostPosted: Tue Apr 25, 2006 6:14 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Is your cable going through RG-59 or RG-6 coax? It only took six feet of the thinner stuff to wipe out my HDTV channels.
View user's profile Send private message
Processor causing A52 CRC Errors
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 2 of 3  
Goto page Previous  1, 2, 3  Next
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin