Hello,
me again..
On Mon, 1 Feb 2010, pl bossart wrote:
In other words - for hardware with large FIFOs, the runtime->delay should be used for queued samples and the hw_ptr in the ring buffer should be increased as soon as the FIFO is filled with samples from the ring buffer.
[...]
- the 'only' change is to make sure the hw_ptr reported in .pointer is
NOT the number of samples pushed out to the interface. hw_ptr should
although, I'm not entirely sure this still makes rewinds fully safe. After driver has called period elapsed and hw_ptr jumps ahead one period worth of samples, the DMA for the next burst/batch is already programmed and possibly ongoing. And with some drivers the burst size (of a single DMA transaction) may be fairly large, while some transfer sample at a time, at codec rate.
This might lead to undefined behaviour when application rewinds upto hw_ptr and starts to refill the segment of the ringbuffer just after hw_ptr, while at the same time DMA engine is already transferring data out of that same ringbuffer segment.
So a safer bet would be to limit rewinds to hw_ptr+X, where X is highly driver/hw specific. At the minimum, 'X >= dma_get_cache_alignment()' (see linux/Documentation/DMA-API.txt) to get deterministic results on different platforms. A sane convervative assumption is 'X >= period-size'.