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

[Takashi Iwai]

At Thu, 12 Jun 2008 12:51:01 +0100,
Colin Guthrie wrote:
> 
> Takashi Iwai wrote:
> >> 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...
> 
> Well in the pulseaudio driver, snd_pcm_delay() will typically *not* 
> return 0 because it will include e.g. network latency.
> 
> Therefore the wine code which *expects* it to return 0 (e.g. waits for 
> it to return 0) does not get the relevant trigger it needs.
> 
> The fact that the implementation detail is included in the docs means 
> that the belief that this function *will* return 0 in all cases when no 
> samples are left to be played is totally understandable. As you and 
> James have confirmed, the snd_pcm_delay() function should return details 
> about the delay expected. The fact that this is the "difference
>  >> between appl_ptr and hw_ptr" does not seem to be correct in all 
> cases/impelmentations.
> 
> I'm no alsa expert so forgive me if I'm just "not getting it". :p

AFAIK, the problem here is that the handling of hwptr isn't
inconsistent in the pulse plugin.  The definition of hwptr is the
point being played (or at least, the point where it was already
processed).  So, it's fine that you take the network latency into
account for calculation of hwptr like the pulse delay callback
actually does.

But, then, pointer callback also must contain the same latency.  If
the hwptr with network latency doesn't work well, then delay callback
shouldn't have the latency as well.


Takashi