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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
