[alsa-devel] What does snd_pcm_delay() actually return?
mznyfn at 0pointer.de
Thu Jun 19 19:59:07 CEST 2008
On Mon, 16.06.08 14:07, Jaroslav Kysela (perex at perex.cz) wrote:
> Hi all,
> I tried to describe expressions for all values as Lennart proposed
> with current snd_pcm_avail_update() / snd_pcm_delay() functions and add
> some more comments to things noted in this discussion. I do not think that
> we should make internal ring buffer pointers external for
BTW, i changed my mind on this one. I now agree that exporting the
pointers is a bad idea, because they are not sufficient to detect the
length of buffer underruns that are more than one buffer size
long. However snd_pcm_avail_updates() informs properly about
those. Hence I think exporting the pointers just like that is a bad idea.
> * LEFT_TO_PLAY: similar to WRITE_TO_HEAR but callable *after* we
> wrote something, and it will return how much of what we wrote has not
> been heard yet. In contrast to WRITE_TO_HEAR this will return 0
> - this accouting can be easily done in app using snd_pcm_delay() -
> application know how many samples were written
This one is actually much more complex. If you want to do it properly
you need to save snd_pcm_delay() before you write something and than
subtract the time passed since that point of time. However the problem
here is that the time passed since then you only get in the system
time domain, while snd_pcm_delay() is in sound card time domain. So
doing this properly is difficult. If you don't care about correctness
you can of course ignore the different timing sources and then the
calculation isn't that difficult anymore.
> int snd_pcm_avail_and_delay(snd_pcm_t *,
> snd_sframes_t *avail,
> snd_sframes_t *delay);
> /* hwsync() + avail_update() + delay() - atomic operation */
This sounds good to me.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel