On Thu, Aug 13, 2009 at 11:46:52PM +0300, Kai Vehmanen wrote: > not strictly related to the patch in question, but this touches on, and is > a good example of, one question I've been wondering for some time now as > an app developer. Could Takashi, Jaroslav, Mark, or others comment on this > as well, perhaps? Dropping linux-omap as this is a generic ALSA question. I'd suggest starting a new thread to discuss this - I'd imagine that several of the people you're trying to get answers from are at best just scanning the thread since it's very large and very OMAP-specific. (Incidentally, can be very helpful to use --no-chain-reply-to when posting large patch sets like this to avoid massive indentation in threaded mail readers). > In both cases, this value (hw_ptr) shows the status of sending data to an > separate entity, and one that has its own buffer (multiple ms) before the > actual DAC/ADC. > But how would a driver expose both bits of info to apps (in a standard > fashion): 1) the hw_ptr for shuffling bits out of the ringbuffer, and 2) > the delay to next played-out/captured sample. For application developers, > (2) is the piece of info we are mostly interested in (if I write a sample > now, how long it will be until it's played out). Both bits of information are very interesting to applications - some applications want to work on the data they're sending for as long as possible (things like pulse which do mixing are the obvious example of this). > Any update/ideas on this topic? Personally I think adding a new driver > callback would make most sense, as that would allow to take full benefit > from hardware that allows to query sample-accurate position of playout > (i.e. not just support exposing a fixed latency). Of course that's > potentially a big change. In alsa-lib, snd_pcm_hwsync() could call this > driver callback, and a new variant of snd_pcm_delay() could present the > information to the applications. If we're adding a new API it should be possible to add one which provides the required information without disturbing the semantics of the existing APIs. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
