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

[Kai Vehmanen]

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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-alsalib-pcmhw-always-use-ioctl-delay.diff
Type: text/x-diff
Size: 873 bytes
Desc: 
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090815/541167e9/attachment-0001.bin