Please don't top-post :-( On Sun, Feb 19, 2006, Ingo Schneider wrote: > 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. Your patch still has a few minor style issue, see my other mail. And please include a shorter version of the above in the patch description, "increase buffersize" is insufficient. I still think it is some other driver which is buggy and screws up irq latency on your machine, however I agree that it's difficult to find out (that's why I suggested the -rt kernel to you, it has patches to address latency problems, and it has tools to debug them). Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
