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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
