2010/2/4 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).
will your propsed hw_ptr move when underrun occur ?
if 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 really represent the next read position in the ring buffer,
this isn't
uniform across drivers. This means for example that the HDAudio implementation needs to modified so that the LPIB value is increased with runtime->delay.