All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <mznyfn@0pointer.de>
To: alsa-devel@alsa-project.org
Subject: Re: What does snd_pcm_delay() actually return?
Date: Thu, 19 Jun 2008 19:59:07 +0200	[thread overview]
Message-ID: <20080619175907.GA8785@tango.0pointer.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0806161329250.1798@tm8103-a.perex-int.cz>

On Mon, 16.06.08 14:07, Jaroslav Kysela (perex@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
> applications.

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
>   eventually.
> - 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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

  reply	other threads:[~2008-06-19 17:59 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-09 19:02 What does snd_pcm_delay() actually return? Lennart Poettering
2008-06-10 14:01 ` RafałMużyło
2008-06-10 14:36 ` James Courtier-Dutton
2008-06-11 16:56 ` Takashi Iwai
2008-06-11 20:24   ` Colin Guthrie
2008-06-11 21:40     ` Tomas Carnecky
2008-06-12 10:25     ` Takashi Iwai
2008-06-12 11:51       ` Colin Guthrie
2008-06-12 12:08         ` Takashi Iwai
2008-06-12 21:00           ` Lennart Poettering
2008-06-13  6:22             ` Takashi Iwai
2008-06-12 20:52   ` Lennart Poettering
2008-06-13  6:13     ` Takashi Iwai
2008-06-13 13:51       ` Lennart Poettering
2008-06-13 13:55         ` Jaroslav Kysela
2008-06-13 14:29           ` Lennart Poettering
2008-06-13  6:59     ` Takashi Iwai
2008-06-13  8:14       ` Jaroslav Kysela
2008-06-13 10:14         ` James Courtier-Dutton
2008-06-13 12:44           ` Colin Guthrie
2008-06-13 13:06             ` Jaroslav Kysela
2008-06-13 14:48               ` Lennart Poettering
2008-06-13 15:02                 ` Jaroslav Kysela
2008-06-13 15:42                   ` Takashi Iwai
2008-06-17  0:53                     ` Eliot Blennerhassett
2008-06-13 14:38           ` Lennart Poettering
2008-06-13 15:27         ` Takashi Iwai
2008-06-13 15:44           ` Jaroslav Kysela
2008-06-13 15:59             ` Takashi Iwai
2008-06-13 16:20               ` Jaroslav Kysela
2008-06-13 16:38                 ` Takashi Iwai
2008-06-13 16:48                   ` Takashi Iwai
2008-06-13 19:55                 ` James Courtier-Dutton
2008-06-16 12:07                   ` Jaroslav Kysela
2008-06-19 17:59                     ` Lennart Poettering [this message]
2008-06-13 19:59                 ` James Courtier-Dutton
2008-06-13 14:25       ` Lennart Poettering
2008-06-13 15:55         ` Takashi Iwai
2008-06-13 16:11           ` Jaroslav Kysela
2008-06-13 16:26             ` Takashi Iwai
2008-06-13 16:47               ` Jaroslav Kysela
2008-06-13 16:52                 ` Takashi Iwai
2008-06-13 17:37                   ` Jaroslav Kysela
2008-06-13 18:23                     ` Takashi Iwai
2008-06-13 18:48                     ` Lennart Poettering
2008-06-13 18:43                 ` Lennart Poettering
2008-06-13 18:29               ` Lennart Poettering
2008-06-13 18:46                 ` Takashi Iwai
2008-06-13 19:01                   ` Lennart Poettering
2008-06-13 19:05                     ` Takashi Iwai
2008-06-13 18:22           ` Lennart Poettering
2008-06-13 18:32             ` Takashi Iwai
2008-06-14  9:51             ` James Courtier-Dutton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080619175907.GA8785@tango.0pointer.de \
    --to=mznyfn@0pointer.de \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.