Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Processor causing A52 CRC Errors Goto page 1, 2, 3  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Processor causing A52 CRC Errors
PostPosted: Sat Apr 01, 2006 9:29 pm Reply with quote
plomba
 
Joined: 01 Apr 2006
Posts: 4




If I so much as run an "ls" command, I get a52 crc errors in my recording. Yet when I monitor the processor usage, it's < 5% utilized during the recording. I tried compiling all of the drivers into the kernel, but it made no difference. I tried recording to a USB drive, but that didn't solve the problem either. Every test that I have run indicates that any other process that performs any action while recording an HD stream (directly, not transcoding), causes these errors!

Any ideas how to fix this?
View user's profile Send private message
PostPosted: Sun Apr 02, 2006 10:41 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




It sounds like you're getting buffer overflows in the driver. If the system is tied up doing something when the driver's buffer fills up, all the data after that is lost. Since data is coming in continuously and the buffer isn't that big, it doesn't take long for it to fill up.

Make sure you're running the latest drivers. I know people have increased the size of the buffer in the driver to help this.

Try increasing the priority of the program that you're recording with. You want to get that processes scheduled as often as possible so it can empty that buffer before it fills up. If it can't get the CPU, it's helpless to stop it from happening.

If you're running a 2.4 kernel (I'm pretty sure I'm the only one still doing that!), increase the timeslicing to 1000HZ. This will caiuse the kernel to use more CPU but it will also cause your recording process to be scheduled more often increasing the chance that it will empty the buffer before it fills up.

There may be other things that are causing your system to be inefficient but these involve kernel tuning and guesswork. For example I've found that adjusting bdflush to spread writes out over time works better than having them write in one massive chunk since that completely monopolized that CPU. There are also virtual memory parameters that you can adjust that may help if it looks like kswapd is running a lot.
View user's profile Send private message
PostPosted: Sun Apr 02, 2006 2:40 pm Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




> It sounds like you're getting buffer overflows in the driver. If the system is tied up doing something when the driver's buffer fills up, all the data after that is lost. Since data is coming in continuously and the buffer isn't that big, it doesn't take long for it to fill up.

How big is the buffer on the card?
View user's profile Send private message
PostPosted: Sun Apr 02, 2006 4:16 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dieter wrote:
How big is the buffer on the card?

Dunno. Not much I guess. You won't be able to increase it if that's what you're asking.

The buffer in the driver is about 2MB (10,000 TS packets).
View user's profile Send private message
PostPosted: Sun Apr 02, 2006 6:32 pm Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




Scott Larson wrote:
dieter wrote:
How big is the buffer on the card?

Dunno. Not much I guess. You won't be able to increase it if that's what you're asking.

The buffer in the driver is about 2MB (10,000 TS packets).


If we know how large the buffer in the card is, we can calculate how often it must be emptied.
View user's profile Send private message
PostPosted: Mon Apr 03, 2006 11:16 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Good point. The 2MB buffer in the driver is about one a second of ATSC. I don't know what buffer is on the card.

Note that the latest DVB driver doesn't appear to log buffer overruns. If you cat the device and suspend cat, the driver doesn't log that data is being lost while the process is suspended. The older 1.4 version of ATSC driver I'm using does properly log buffer overruns. That's helped me distinquish computer problems from reception problems.
View user's profile Send private message
Buffer Overruns
PostPosted: Sun Apr 09, 2006 6:30 am Reply with quote
plomba
 
Joined: 01 Apr 2006
Posts: 4




I have compiled the latest 2.6.16.1 kernel and do not see a difference. I'll see if I can recompile and change the timeslicing, though. I had to stop the Apache service because everytime I loaded a web page while it was recording, the audio drops out and the video will get artifacts.
View user's profile Send private message
PostPosted: Sun Apr 09, 2006 11:28 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




You will almost certainly experience these kinds of problems if you're using your HTPC for anything other than watching HDTV. I would never run a web server off of an HTPC and expect perfection. I can't even load a page in a browser on my system without losing a frame or two. Even moving the mouse around can drop a frame or two, but then I'm running a 2.4 kernel which doesn't have the improved scheduler that the 2.6 kernel has.
View user's profile Send private message
A52 Errors
PostPosted: Fri Apr 14, 2006 3:15 pm Reply with quote
plomba
 
Joined: 01 Apr 2006
Posts: 4




I can't even run an ls command without getting errors though. If the processor utilization is < 5%, why would it be dropping frames? It just seems a bit odd to me.

If I disable EVERYTHING and only record, then it plays back fine, and the picture and sound are incredible. If I try to play without first recording, though, I can't watch it. And if I try to watch while I'm recording, the recording is garbled starting at the point when I loaded the program to watch it (mplayer). Mplayer uses a lot of CPU, though, but the 'ls' command should definitely not corrupt the incoming stream of data, IMHO.

You can say that a HTPC should be specialized, and you're right. But why would live capture of analog TV work fine while playing music, watching a movie, serving up a web page, and doing a million other things, and all while using a $30 bottom of the line TV capture card? It just seems like the drivers for this card either aren't buffering right, or, well, aren't buffering right.

.. it could be the fault of the kernel too. I really am no expert on this stuff.
View user's profile Send private message
PostPosted: Sat Apr 15, 2006 2:53 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




CPU utilization is just one way a task can get delayed in Unix. There is tons of locking in the kernel for example. I believe X has a lock that prevents even XvMC from updating the display. Since this passes some tasks onto the display hardware when it's locked, the CPU could certainly be idle while it waits for other hardware to finish. Try running "ls > /dev/null" to see if that what's causing it.

The same thing can apply to disk drives. I had a client that had a slow system even though the CPU was free as a bird. It turned out that there was something wrong in the SCSI hardware that was making disk accesses take forever. This should have printed something in /var/log/messages but the manufacturer accidentally disabled that code in the driver we were using. Apparently it's difficult to test for all failure conditions in drivers.

What are you capturing analog TV on? If you're using a card with a built-in MPEG encoder than that's no load on the system at all. Tivos have something like a 70 Mhz CPU since everything is handled in other hardware.

We're assuming you're using fairly fast hardware of course.
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 5:10 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




I think the digital demodulator is very touchy to RF problems.

I can capture analog with no problems. Moving windows, compiling, nothing is a problem. Using tvtime, my system is about 83% idle when using analog.

If I try to watch a SD digital channel, my system is 90% idle. It actually takes less CPU than with analog. But any X activity causes massive dropouts. It's not mplayer, and it's not a buffer overflow in the driver. The cx23883 chip thinks it is getting bad data from the demodulator. The packets are never getting to the DVB driver, much less mplayer or the X server.
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 10:44 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




If it's affecting the reception then you should see the signal quality drop in dtvsignal (or the dvb equivalent) when this is happening.
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 11:56 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
If it's affecting the reception then you should see the signal quality drop in dtvsignal (or the dvb equivalent) when this is happening.


I don't think the SNR measurement that the driver returns for QAM is correct. I think pretty much completely meaningless in fact. It only appears to have two settings, 99% and 0%.
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 6:47 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Then how are you measuring this?
View user's profile Send private message
PostPosted: Mon Apr 17, 2006 6:53 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Didn't we also determine that the DVB driver isn't logging buffer overflows? If you cat the device to null and then suspend the cat, data from the card is lost but there isn't a peep about it in /var/log/messages. With the ATSC driver, I get this message within a second:

Code:
Apr 17 18:53:08 localhost kernel: cx88atsc: buffer overrun
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 1 of 3  
Goto page 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