Hi,
On Fri, 14 Aug 2009, Clemens Ladisch wrote:
snd_pcm_delay() returns the filled part of the buffer plus the additional delay imposed by the device.
[...]
The additional delay can be set by the driver in pcm_substream->runtime->delay. (Currently, only the USB audio driver bothers to set this.)
aa, now that's interesting, and I think that's just the missing piece I'm looking for. I was looking at the 2.6.30.4 kernel, and couldn't find any traces of 'runtime->delay', but oh yes, 2.6.31 tree indeed has it - yay! :)
It would seem this was added by Takashi with commit "ALSA: Add extra delay count in PCM" on 2009-05-05, so no wonder not too many drivers set it yet.
Hmm, but isn't it so that this extra delay is added properly to snd_pcm_delay() result, when 'sync_ptr_ioctl==false' property is set for the pcm (i.e. use SYNC_PTR ioctl instead of mmap control structures). Attached is an alsa-lib patch attempting to fix this (as sufficient info is not available in the mmap control block, always go via IOCTL_DELAY).
But otherwise this does look good and is just what I was looking for. When using snd_pcm_status(), application can get all the information (avail, delay) in one go. Of course one limitation is that the runtime->delay updates are synced to driver events, not to application calling snd_pcm_delay (unlike query of hw_ptr status via pointer driver callback), but maybe this is not even needed in the end. Have to think about this some more...
Thanks Clemens, James and Mark for the quick replies!