[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Thu Jun 12 12:25:51 CEST 2008
At Wed, 11 Jun 2008 21:24:20 +0100,
Colin Guthrie wrote:
> Takashi Iwai wrote:
> > At Mon, 9 Jun 2008 21:02:25 +0200,
> > Lennart Poettering wrote:
> >> Takashi, Jaroslav,
> >> could you please explain what exactly snd_pcm_delay() returns?
> >> Some applications (such as WINE) assume it is the time that would pass
> >> until we reach an underrun if we would stop writing any further data
> >> to the PCM device.
> >> Other applications (such as most media players) use it for time
> >> synchronisation. i.e. assume that it is the time that passes until a
> >> sample I write to a PCM device now would take to be played.
> > As James already pointed, the correct answer is the latter.
> > In the driver implementation level, snd_pcm_delay() simply returns the
> > difference between appl_ptr and hw_ptr. It means how many samples are
> > ahead on the buffer from the point currently being played.
> > However, if you stop feeding samples now, snd_pcm_delay() returns the
> > least time XRUN occurs. So the first understanding isn't 100% wrong.
> > The implementation of snd_pcm_delay() (at least in the driver level)
> > purely depends on the accuracy of PCM pointer callback of each
> > driver. So, if the driver returns more accurate hw_ptr via pointer
> > callback, you'll get more accurate value of snd_pcm_delay(). In the
> > worst case, it may be bigger up to one period size than the real
> > delay.
> I could be wrong here as I'm only going on discussions I've had with
> wine folks rather than poking at the code myself (I did look a while
> back but I've forgotten it all now!).
> AFAIK, the way Wine uses snd_pcm_delay() is to check when a sample is
> fully played. e.g. they wait for the function to return 0.
It returns 0 or a negative value, or returns error EPIPE which means
buffer underrun, dependong on the setup. XRUN detection can be
Anyway, use snd_pcm_delay() to determine the hwptr is correct.
But, of course, this doesn't guarantee the accuracy of hwptr because
its accuracy depends on the driver.
> I think this
> was done due to the docs specifically say that it is the "difference
> between appl_ptr and hw_ptr" so it makes sense to assume this will
> return 0 when there is nothing waiting to be played. I would strongly
> recommend that you remove the implementation detail from the (supposedly
> high level) docs.
Why? I don't see your logic...
More information about the Alsa-devel