[alsa-devel] What does snd_pcm_delay() actually return?
mznyfn at 0pointer.de
Fri Jun 13 16:48:50 CEST 2008
On Fri, 13.06.08 15:06, Jaroslav Kysela (perex at perex.cz) wrote:
> The comment for snd_pcm_delay() in alsa-lib is clear and it's what James
> wrote. If only one app interprets this wrongly, then I agree it would be
> better not to change original meaning.
> Then we have snd_pcm_avail_update(). Although it is stated in comment that
> this function is useless for non-mmap mode, it's quite clear that returns
> number of available frames to be handled (r/w) by application.
> The easiest method would be just to remove "useless for non-mmap" from
> comments for snd_pcm_avail_update() and suggest to application developers:
> 1) overall latency is returned by snd_pcm_delay()
> 2) ring buffer filling is controlled by snd_pcm_avail_update(), for
> non-mmap access is usage of this function optional
> As mentioned, it will need to fix some drivers mixing software output FIFO
> with ring buffer (USB, PCMCIA)..
Sounds good to me, on first sight.
Hmm, however, there is one thing I'd still need for PulseAudio:
I'd like to know when (in time units) the playback buffer would
underrun from now on if I don't write anything anymore. For the USB
driver at least this happens much earlier than just calculating
(buffer_size - snd_pcm_avail_update()) and transforming that into time
units, because the USB driver seems to remove a block at a time from
the playback buffer, and hence it will signal the XRUN much earlier
then the aforementioned value. To fix this I'd need to know what this
granularity is. If I knew that I could fix my sleep time accordingly.
In short: I need some kind of granularity information about
snd_pcm_avail_update() but I must admit that right now I am not
actually sure which parameter would be the best one to know about.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel