[linux-dvb] Re: [PATCH] fix for stream corruption on budget /Nova-T cards

[Jon Burgess <mplayer@jburgess.uklinux.net>]

Robert Schlabbach wrote:
> 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 ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.