On 10/24/2012 05:16 AM, Maarten Lankhorst wrote:
I'm not sure yet how dsound should be fixed on bigger periods, I believe using IAudioClock for reporting position *might* be the correct answer, but it's not properly test yet on behavior, so I chose for the simple solution of directly reporting next mix position as play pos, which is the same as current code.
...
At the point dsound queues the data to mmdevapi it can no longer do anything about it, so instead of trying something more complicated the best way to deal with it is to accept that fact and keep queued latency as fixed as possible, and ideally small.
FWIW, I agree. With OpenAL Soft, the "read" position of a sound is reported by simply using the next update position, and the "write" position is one period size ahead of that. The underlying output mix buffer is set to a fixed size with fixed update lengths (and where PulseAudio is concerned, makes sure to use PA_STREAM_ADJUST_LATENCY to keep its own latency in check). This seems to me to be more than adequate, even when using a custom dsound->openal wrapper.