[PATCH 5/6] dsound: rework ugly mixer logic

[Chris Robinson]

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.