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). _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
