At Thu, 12 Jun 2008 23:00:06 +0200, Lennart Poettering wrote:
On Thu, 12.06.08 14:08, Takashi Iwai (tiwai@suse.de) wrote:
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.
But we need the network latency in there, because it is necessary for doing a/v synchronization. The network latency can be quite substantial.
That's why I suggest to fix hwptr to consider the network latency in the first place.
The "hw_ptr/appl_ptr" is just too simple to cover the networked cases.
Likely. The hwptr/applptr model was designed for PCI-DMA h/w, and doesn't suit with the queue style implementation, indeed. IOW, it's optimized for mmap-style access.
Takashi