Re: safe support for rewind in ALSA

[pl bossart <bossart.nospam@gmail.com>]

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

Well, we went from my interpretation that was completely broken to
something that can still be broken at times...
 If you really want to be safe, you'd need a means to specify this X
value for your system. Actually it would make a lot of sense to do so.
On most embedded systems the DMA bursts and buffering in FIFOs can be
programmed. It'd be nice to have the ability to set different values
for DMA bursts and delay depending on the mode (low-power,
low-latency, etc).