From: Lennart Poettering <mznyfn@0pointer.de>
To: alsa-devel@alsa-project.org
Subject: Re: Misusing snd_pcm_avail_update()
Date: Thu, 22 Jan 2009 23:20:15 +0100 [thread overview]
Message-ID: <20090122222015.GB9379@tango.0pointer.de> (raw)
In-Reply-To: <s5hwscpqypo.wl%tiwai@suse.de>
On Wed, 21.01.09 01:39, Takashi Iwai (tiwai@suse.de) wrote:
> > The function should look like this:
> >
> > snd_pcm_sframes_t snd_pcm_busy_for(snd_pcm_t *pcm);
> >
> > I called the prototype "busy for" since effectively the value I am
> > looking for is the time the card will be busy with the data it already
> > has, and doesn't need any new data.
>
> Isn't it snd_pcm_delay() that was originally designed for?
No. Let me summarize the meaning of snd_pcm_update_avail(),
snd_pcm_delay() and my snd_pcm_busy_for() to opefully make clear where
the differences are:
snd_pcm_update_avail() -- returns how many samples can be written
right now without blocking.
snd_pcm_delay() -- returns how many samples will be played before the
samples that are written now can be heard.
snd_pcm_busy_for() -- returns how many samples will be played before
ALSA would enter an underrun situation if no
further samples are written.
snd_pcm_update_avail() and snd_pcm_busy_for() return metrics that are
solely dependant on the size and metrics of the hardware buffer and
its current indexes. snd_pcm_delay() also includes information about
any extra latency that comes after the playback buffer.
Onle snd_pcm_update_avail()/snd_pcm_busy_for() are influenced by "fast
starts" as done by the USB driver's double buffering and by
block-based transfer.
Hmm, I am trying my best to explain why I want this function and what
exactly it should do. Any chance I can convince you guys that this
function really matters for timer-based audio scheduling?
> Did you check my previous patch?
You mean the one that makes snd_pcm_delay() for USB devices actually
include the extra latency that comes after the playback buffer? No, I
didn't check that one yet. It takes so much time to patch the kernel
and test things... I'll try too finally do it this WE.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
next prev parent reply other threads:[~2009-01-22 22:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 2:57 Misusing snd_pcm_avail_update() Lennart Poettering
2009-01-20 8:29 ` Clemens Ladisch
2009-01-20 8:32 ` Clemens Ladisch
2009-01-20 14:26 ` Lennart Poettering
2009-01-20 18:48 ` Clemens Ladisch
2009-01-20 20:29 ` Lennart Poettering
2009-01-21 0:39 ` Takashi Iwai
2009-01-22 22:20 ` Lennart Poettering [this message]
2009-01-23 17:13 ` Takashi Iwai
2009-01-23 17:56 ` Clemens Ladisch
2009-01-24 9:52 ` Takashi Iwai
2009-01-28 18:30 ` Lennart Poettering
2009-01-29 8:28 ` Clemens Ladisch
2009-01-28 18:26 ` Lennart Poettering
2009-01-23 18:49 ` 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=20090122222015.GB9379@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.