Re: safe support for rewind in ALSA

[Raymond Yau <superquad.vortex2@gmail.com>]

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.