[alsa-devel] safe support for rewind in ALSA

[Kai Vehmanen]

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'.