Ingo Schneider wrote:
Hi !
That's why I'm making sure that the buffer width is a multiple of 376
and the buffer height is a multiple of 256.
Without that, I got corrupted data !
I tried some different widths (376, 752, 3760, but only 376, 752 are
used with that algorithm)
and some heights (1024, 1280, 2048, 2816, 3840) and with that it
always worked (for my cards, off course).
DMA buffer bigger than 4 MB doesn't work - and it also makes no sense
to use more buffer than needed under high load.
In the "refactored patch" with the recommendations of Oliver I keep
the buffer size as it was before (because it's untested for other card
types),
and only change the buffer layout if module parameter is set, so there
should be no new problems with that.
With the buffer warnings we'll see if other people have problems with
a too small buffer, too.
With a buffer size of 470k (376x1280) I now get a perfect TS stream
(good data, no TS continuity problems),
even under very high I/O load conditions.
Now the best thing to do is to integrate it and see if I'm the only
one having problems with too small DMA buffer.
Regards,
Ingo Schneider.
I have to say that I am also having issues with to small of a DMA
buffer. This is using a saa7135 with the nxt2004 processor on my Kworld
card.
I would experiment with increasing the buffer size for the driver my
card uses but I think there are other issues in software that are
contributing to my problems. Everything works nice and smooth under
windows but under Linux my sound studders a lot and mplayer says there
are crc errors. If I simply disable the DMA channel for sound then
everything is smooth and no CRC errors. The audio is very minimal
compared with the video so I think there is a setup issue in my case.
Curt
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
