From: "Jon Burgess" <[EMAIL PROTECTED]> > I wonder why we bother using both the ODD & EVEN buffer at all. The > distinction doesn't appear relevant when the chip is dealing with raw > DVB data and not interlaced video fields. Perhaps we should just use one > field buffer and double it's size. This should simplify things a bit, it > seems to be this transition between the two fields which causes the > ambiguous DMA pointer in the first place.
I think the odd/even buffer are used to overcome a sensitive timing issue - keep in mind that there is no such thing as a "vertical blanking" in a DVB data stream. The only "breathing time" between two MPEG-2 transport packets are those 16 bytes Reed-Solomon redundancy. Now consider a DVB-Satellite stream blasting at you with 40Mbps, and realize that you have no more than _3 microseconds_ to reprogram the DMA pointers, or packets will either be overwritten or lost. The odd/even trick makes the SAA7146A automatically switch between two buffers. The ugly side of this is that you have to busy-wait for it to really switch buffers and then _copy_ the data out of the DMA buffer. A much more elegant solution would be to completely rewrite the budget transfers to utilize an SAA7146A RPS task to directly DMA the data to the output buffers so that no additional copying is necessary. But that takes a whole lot of fiddling to really make work without dropped packets - I spent a few weeks implementing this in my Windows BDA driver... Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
