[alsa-devel] snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)

[Mark Brown]

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