[alsa-devel] safe support for rewind in ALSA

[Jaroslav Kysela]

On Mon, 1 Feb 2010, Mark Brown wrote:

> 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.

+1 - the runtime->delay is exactly for this information (number of 
samples queued in hardware) and can be changed in the lowlevel driver at 
runtime depending on the actual hardware state.

 					Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.