[alsa-devel] What does snd_pcm_delay() actually return?

[Jaroslav Kysela]

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

Opinions?

					Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.