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