[linux-dvb] Re: probably driver bug...

[Guido Fiala <gfiala@s.netic.de>]

> me wrote:
>  > Recently i mentioned that since kvdr can do Xv me and other people
>  > observe short horizontal green or pink lines at the display (color space
>  > conversion might affect actual color).
>  >
>  > To track that down to a certain component i tried the following
>  > combinations:
>  >
>  > -Xv on dvb "playing" - above glitches <#########
>  > -grabbing images on a playing dvb - occasional glitches <#########
>  > -Xv on dvb "live" - no glitches
>  > -Xv on dvb "recording" - no glitches
>  > -Xv on primary dvb while secondary recording - no glitches
>  > -Xv on secondary while primary playing - no glitches
>  > -Xv on analog WinTV feeded with the output of a playing dvb - no
>  > glitches -grabbing images on recording, live dvb - no idea if or if not
>  > (can someone verify?)
>  > -disk activity in general as mentioned earlier is not the problem!
>  >
>  > Conclusion:
>  > There seems to go something wrong in the dvb-driver with the mem-map'ed
>  > IO during grabbing, probably reading that memory addresses returns all
>  > zero's for that part of the image. It is a short term problem - just one
>  > frame - occuring more or less distributed over the entire screen and
>  > very annoying :-(
>  >
>  > Is there any hope to fix that in the dvb-driver or is it a firmware
>  > related problem?
>
> Those glitches don't seem to be errors in the MPEG stream, which
> usually look more like blocks. It could be a problem with PCI latency,
> although that usually shows up all the time. If the TV out shows a
> correct picture it has something to do with the DMA into video memory,
> which is not influenced by the firmware.
> What kind of chipset does your board have ?

Tekram BX, P2-450

> What graphics card?

V3K

> Is it limited to the screen resolution, or maybe size of the picture?

Nope.

> Is it present when not using Xv, e.g, with tuxview?

Only using any kind of PCI-memory.

> Is it limited to one type graphics card?

A G400 showed it as well.

---------------------------------

Since then i started some investigations and tryed to solve that problem.
The saa7146-spec has a sentence that makes me nervous:
".. if the (video) FIFO gets an underrun the correscponding pixels get 
deactivated" - hopefully that is'nt occurring here...

To state it clearly:
The stripes (about 20 .. 512 bytes long) appear only in replay-mode and only 
if the video-data is'nt written to AGP but _PCI_ memory (otherwise they would 
be visible on overlay as well).

I guess it can be interfering between the various DMA-channels in combination 
with the (longer) data-transfer from card to PCI (rather than AGP). These are 
- DEBI, Audio 1..4, Video 2..3. Are there other things that can interfere?

I would appreciate any help or hints to track that down, as a lot of people 
are observing that problem, it's not graphics-card related, but maybe chipset 
related?

The solution might be a change to the RPS-task0 as set up in saa7146.c, as a 
beginning i tried to deactivate the DEBI-transfers during video-DMA1 but it 
did'nt solve the problem but wrecked the thing completly *g*. 
Can someone explain how and were the driver 
get's fed with the replayed MPEG2-data?
What things can/should i deactivate during that video-DMA? What about the 
RPS-task1 interfering with task0?
Are there ongoing i2c-transfers during replay?
How are the data transfered into AGP-memory (as it's not done via task0) and 
why can't we do the same into PCI-memory?

BTW - reducing the FIFO's size to 4 bytes in saa7146_core.c one get's funny 
artifacts on the overlay and i could "increase" the problems with the lines, 
increasing the FIFO to max however did'nt helped to solve the problem either.



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.