[alsa-devel] snd_pcm_delay, hw buffers and driver api (v2)

[Kai Vehmanen]

Hi,

[ continuing to restart the thread. Here's a reply to Mark's mail to the
   original misplaced thread at:
   http://kerneltrap.org/mailarchive/alsa-devel/2009/7/30/6272573 ]

On Thu, 13 Aug 2009, Mark Brown wrote:
> On Thu, Aug 13, 2009 at 11:46:52PM +0300, Kai Vehmanen wrote:
>> 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).

For sure, that's true. I was meaning to say, that when using 
snd_pcm_delay(), (2) is what applications are mostly interested in. But 
yeah, snd_pcm_avail()/snd_pcm_avail_delay() are certainly important to 
applications as well. But I initialled ignored this part, as it would seem 
this part of the API is already in good shape (especially after the recent 
updates like snd_pcm_avail_delay()).

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

For sure. Changes to e.g. snd_pcm_delay() semantics (especially with 
current set of drivers) would cause no end of nasty bugs, agreed. Probably 
reusing snd_pcm_hwsync() is a bad idea as well. Maybe just add a new 
snd_pcm_hwdelay() or some such which calls the new driver callback (-> 
provides an atomic snapshot of snd_pcm_avail_delay + fill-status of ext-hw 
buffers).