[alsa-devel] snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)
broonie at opensource.wolfsonmicro.com
Thu Aug 13 22:59:23 CEST 2009
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
> 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.
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Alsa-devel