>The source buffer doesn't matter after we have filled the DMA buffers, >does it?
Ah, you are right, I forgot about the fact we did an additional copy here. Too bad we can't just DMA from the source buffer, that sucks, remember the RAM throughput of most Macs isn't that good... This is probably one reason why DMA doesn't show that a significant perf improvement. >Anyway, I don't see any explicit synchronisation in the driver, so >probably the problem is the players calling XSync(). Well, do we wait for DMA to finish or not ? If we do, then we are doing explicit sync. If we don't, then we should, at least, wait on frame N+1 wait for frame N to finish. The point is to have at least one frame in advance to not busyloop when there is still work to do. The ideal case would be to block on command completion using an IRQ of course. XSync() can be faked. We can perfectly decide to buffer one frame in advance, can't we ? Then XSync on the next frame, thus we won't block on double buffer setup if the second buffer isn't filled. That make sure we only block (or spinloop) if the decoder is feeding us faster than the framerate, and only when we have the 2 buffers filled. That should smooth the whole data flow and avoid a lot of useless sleeps/busyloops. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
