[alsa-devel] safe support for rewind in ALSA
superquad.vortex2 at gmail.com
Mon Feb 8 02:22:56 CET 2010
2010/2/4 pl bossart <bossart.nospam at 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.
> > driver has called period elapsed and hw_ptr jumps ahead one period worth
> > samples, the DMA for the next burst/batch is already programmed and
> > ongoing. And with some drivers the burst size (of a single DMA
> > may be fairly large, while some transfer sample at a time, at codec rate.
> > This might lead to undefined behaviour when application rewinds upto
> > and starts to refill the segment of the ringbuffer just after hw_ptr,
> > 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
> > 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,
>> uniform across drivers. This means for example that the HDAudio
>> implementation needs to modified so that the LPIB value is increased
>> with runtime->delay.
More information about the Alsa-devel