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'. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
