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.
From what I can tell we already configure the "limit3" parameter which should cause the saa7146 to send us an interrupt for every 16kB of data DMA'd. Here is the text from the datasheet:
If the limit register of any DMA channel (video, VBI data or audio) has a value other than ‘0000’ the continuous write mode is chosen. ... .The SAA7146A offers the possibility to monitor the filling level of this memory space. The limit register defines an address limit, which generates an interrupt if passed by the actual PCI address pointer. ‘0001’ means an interrupt will be generated if the lower 6 bits (64 bytes) of the PCI address are zero. ‘0010’ defines a limit of 128 bytes, ‘0011’ one of 256 bytes, and so on up to 1 Mbyte defined by ‘1111’. This interrupt range can be calculated as follows: Range = 2^(5 + Limit) bytes.
On receipt of the IRQ the driver processes the latest data from the ring. As long as the driver manages not to get behind by a complete ringbuffer of data, then nothing is ever lost.
I interpreted the "continuous write mode" to mean that the chip would automatically cycle back around to the start of the buffer.
From what I can tell there should be no difference between using one buffer of full size or two buffers of half the size.
I agree that a different programming model could be used where we use two buffers and read them alternately as they become full. This would reduce the interrupt loading on the system.
> 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.
That would be OK for receiving the whole TS, but I doubt that the RPS is clever enough to do the PID filtering (I could be wrong - I don't know any details about the RPS programming).
Jon
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
