[alsa-devel] What does snd_pcm_delay() actually return?
perex at perex.cz
Fri Jun 13 15:06:09 CEST 2008
On Fri, 13 Jun 2008, Colin Guthrie wrote:
> James Courtier-Dutton wrote:
> > Jaroslav Kysela wrote:
> >> On Fri, 13 Jun 2008, Takashi Iwai wrote:
> >>> - Add some new API functions,
> >> I would prefer to extend the current API than to change meaning of hw_ptr
> >> to handle extra latencies.
> > I would prefer the definition of snd_pcm_delay() to be:
> > Before the next sample is written to the buffer, snd_pcm_delay() returns
> > the expect time delay, in frames, indicating the time the next sample
> > will reach the speakers.
> > This is what snd_pcm_delay() was introduced into the ALSA api for. I
> > remember, because it was added as a result of me requesting it.
> > Then implement a totally different api call to help with under run timings.
> Big +1
> You also have to think of the use cases currently out there.
> * World + Dog uses it as James (and Lennart) states.
> * Wine uses it sans latency.
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)..
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel