[alsa-devel] safe support for rewind in ALSA

[Mark Brown]

On Mon, Feb 01, 2010 at 11:20:25AM -0600, pl bossart wrote:

> My suggestion would be to add a 'fifo' parameter to the runtime
> structure (so that it's visible to the core), let the driver developer
> fill the value in the .open routine, and use this parameter in rewind
> to prevent rewinding too much. This parameter would include both
> hardware FIFOs and DMA buffers.

I think we want to split these concepts out a bit - with some devices
the stuff that's in the FIFO is not represented to the ALSA data
management code because it's past where the DMA controller says it's
working and trying to retrofit the data into what the DMA controller
reports gets too complicated.  I'd also expect a degree of lumpiness in
the memory regions the DMA controller is working on which it might be
useful to convey to applications.  Perhaps for the DMA we could add a
pointer for the first area the CPU can currently access safely?

For FIFO style latencies I think we'd want to allow the value reported
to be variable (since for example changes in any DSP algorithms that are
active could change the latency), and since it's not entirely joined up
with the DMA itself it might be better to just explicitly report to
applications and let them figure out what they think is a sensible way
of dealing with it.  This seems easier than trying to integrate the
information with the DMA data and more useful for latencies which we
know as actual time delays rather than buffer sizes in the hardware.