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
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Tue Apr 25, 2006 9:42 pm Reply with quote
theyneverknew
 
Joined: 19 Apr 2006
Posts: 12




Seeing as I can record things perfectly under every circumstance except watching live on the local machine I'm fairly certain that it's not an issue with the cable input.

I've also tried increasing the PCI latency timer of the pcHDTV card and decreasing all other PCI latency timers, but that also didn't solve the problem.
View user's profile Send private message
PostPosted: Wed Apr 26, 2006 11:26 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
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.

Of course how lspci describes devices is arbitrary.

So the pci.ids database isn't good enough for you? How about the cx23880 datasheet, is that an acceptable reference?
Quote:

1.2.5 MPEG Data Port
Channel demodulators used for digital television or broadband data applications over terrestrial, satellite, or cable networks can be directly connected to the CX2388xs MPEG data port to deliver transport streams to the host for subsequent storage to disk or software decode. Either parallel, common-interface Digital Video Broadcasting (DVB) or serial data paths from the channel demodulator can be supported at data transfer rates of up to 80 Mbps. If the Serial Interface mode is used, the remaining unused pins on this port can be allocated as General Purpose Input/Output (GPIO).

Scott Larson wrote:

Now how do you know you weren't getting buffer overflows again?

Go download the cx23880 datasheet, and read the section on the "MPEG data port", or whatever you want to call it. Sections 2.5 and 6.9 are the ones you want to look at. The bit about the SRAM FIFO overflow counter is the relevant part. I explained here what was necessary and exactly which functions needed to be modified.
View user's profile Send private message
PostPosted: Wed Apr 26, 2006 12:02 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




theyneverknew wrote:
I've also tried increasing the PCI latency timer of the pcHDTV card and decreasing all other PCI latency timers, but that also didn't solve the problem.

I tried that too, but it didn't help either. The cx88's SRAM FIFO is setup to hold 20 TS packets. 256-QAM sends 25,830 packets/sec. So there is a buffer for about 774 microseconds of data. Compare to the precursor of the cx23880, the Bt878, which for analog NTSC capture at CCIR.701 resolution had a FIFO for just 20 microseconds worth of data. With a 20 us max bus latency, the PCI latency values make a difference. 774 us is enough that it doesn't matter.

Tune the card to a digital channel with azap or mplayer and then exit it. Now try running 'dvbtraffic | grep ^2000' in an xterm. That should print out once per second how many packets you are getting, which should be 25,830 for 256-QAM. Now try dragging windows around in X. Does that make the value drop? It does for me if I use the nvidia driver, but not if I use the nv driver. I can start a kernel compile with make -j3 without dropping packets, as long as I keep the output from scrolling on an xterm.
View user's profile Send private message
PostPosted: Wed Apr 26, 2006 12:47 pm Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




> It does for me if I use the nvidia driver, but not if I use the nv driver.

So use the nv driver.

It sounds like the nvidia driver must be hogging the CPU
for too long, at a spl higher than the hd-3000.
View user's profile Send private message
PostPosted: Wed Apr 26, 2006 1:12 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




dieter wrote:
> It does for me if I use the nvidia driver, but not if I use the nv driver.

So use the nv driver.

It's slower than the nvidia driver, and doesn't support XvMC or fast OpenGL.
View user's profile Send private message
PostPosted: Wed Apr 26, 2006 1:18 pm Reply with quote
theyneverknew
 
Joined: 19 Apr 2006
Posts: 12




I just tried with the nv driver instead of the nvidia driver and I didn't experience the signal problems, but as xyzzy said using the nv driver isn't a good solution since it doesn't support xv or xvmc output of video which makes watching HD streams basically impossible.

Edit: Next I tried using the nvidia driver, but specifying -vo x11 for mplayer and the corruption once again went away, but mplayer eventually dies because of too many packets in the buffer since it can't decode the stream fast enough with -vo x11. It seems that using any of the accelerated graphics functions of the nvidia driver is what's causing the problem.
View user's profile Send private message
PostPosted: Mon May 01, 2006 10:35 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
It does for me if I use the nvidia driver, but not if I use the nv driver. I can start a kernel compile with make -j3 without dropping packets, as long as I keep the output from scrolling on an xterm.

Why does output scrolling in an xterm make a difference? Is this with both drivers?

Over the weekend I got my system working with QAM 256 with the pcHDTV (not DVB) 1.6 drivers. The only problems I had were buffer overruns when I moved windows around (the non-DVB driver does log buffer overruns).
View user's profile Send private message
PostPosted: Tue Aug 15, 2006 7:15 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




I finally had enough with Comcast's defective DVR needed to get most channels and canceled my cable. I couldn't justify $80 a month for TV anyway.

So I put up an antenna:


Yes, that's just a cable with nothing on it hanging from the eaves. This was enough to get digital reception from 7 of the 8 channels near me. But a couple of them had marginal levels, and KCPQ from 20 miles away was around the 20% level.

So I made an antenna booster:

With this high-tech hardware, I get all eight ATSC stations without trouble on my HD-3000.

I can watch them with mplayer using the nvidia driver with no troubles. X activity doesn't seem to be effecting reception with 8-VSB the way it did with 256-QAM. I have to conclude that 256-QAM is more sensitive to noise than 8-VSB, and that the noise in the power rails generated by a graphics card is enough to kill 256-QAM reception in the HD-3000 card.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 9:54 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Did you have the cable company check the signal strength going into your cable box (or PC)? My HD cable box had occasional lockups on some HD channels. They sent a guy out who quickly noticed that a squirrel had nibbled through the drop from the pole. This was just enough to cause problems on channels above 800 Mhz. They replaced the cable drop and it solved everything.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 1:04 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Had them out several times, they never found anything wrong.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 7:32 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




What kind of signal strength was your cable box showing? I was getting dropouts on my Moto box even at 85%. The replacement cable sent it up to 95%.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 9:10 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
What kind of signal strength was your cable box showing? I was getting dropouts on my Moto box even at 85%. The replacement cable sent it up to 95%.

I don't remeber what the box said for the AGC setting. The SNR was around 35 dB, which is plenty. I think the problems were with the microsoft software on the box. It would not record things it was supposed to record, and lock up constantly. When it screwed up the recordings of TdF stages 16 and 17, that was the last straw.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 10:54 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
Scott Larson wrote:
What kind of signal strength was your cable box showing? I was getting dropouts on my Moto box even at 85%. The replacement cable sent it up to 95%.

I don't remeber what the box said for the AGC setting. The SNR was around 35 dB, which is plenty.

Or maybe not plenty with your PC hooked up to it?
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 3 of 3  
Goto page Previous  1, 2, 3
  
  
 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