MSDN implies that, by default, the play cursor position reported by GetCurrentPosition may be inaccurate on "emulated sound cards." This seems important since we're using the difference between the play and write cursors to estimate the latency.
There's a flag you can set when you create the buffer that tells DirectSound you want a more accurate position. In the DSBUFFERDESC flags field, there's an option called DSBCAPS_GETCURRENTPOSITION2. MSDN says:
There's a flag you can set when you create the buffer that tells DirectSound you want a more accurate position. In the DSBUFFERDESC flags field, there's an option called DSBCAPS_GETCURRENTPOSITION2. MSDN says:
The buffer uses the new behavior of the play cursor when IDirectSoundBuffer8::GetCurrentPosition is called. In the first version of DirectSound, the play cursor was significantly ahead of the actual playing sound on emulated sound cards; it was directly behind the write cursor. Now, if the DSBCAPS_GETCURRENTPOSITION2 flag is specified, the application can get a more accurate play cursor. If this flag is not specified, the old behavior is preserved for compatibility. This flag affects only emulated devices; if a DirectSound driver is present, the play cursor is accurate for DirectSound in all versions of DirectX.
This may be true, but I believe sometime during day 19, Casey tried adding this flag and it didn't change anything noticeable. So it may indeed help for some systems, but there were bigger issues with the code at the time.