[alsa-devel] snd_pcm_delay, hw buffers and driver api (v2)
kvehmanen at eca.cx
Sat Aug 15 01:27:56 CEST 2009
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 18.104.22.168 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
Thanks Clemens, James and Mark for the quick replies!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 873 bytes
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090815/541167e9/attachment-0001.bin
More information about the Alsa-devel