I recently discovered a bug in waveOutGetPosition on some (maybe all?)
Pocket PC's.
The bug is the following:
When position.wType = TIME_MS, a call to waveOutGetPosition(wave_handle,
&position, sizeof(position)) is supposed to return the output wave position
in milli-seconds in position.u.ms.
See the documentation for waveOutGetPosition and MMTIME.
But the value returned in position.u.ms is NOT the wave buffer position in
milliseconds (e.g. on the e800, the value seems to be expressed in 1/100,000
sec).
This problem likely comes from the fact that MSFT provided no test for the
OEM to check the correct implementation of their audio driver with regard to
this function.
When position.wType = TIME_SAMPLES, position.u.sample is the correct number
of un-played samples in the wave driver's queue. The TIME_SAMPLES case is
well tested because that's how all the video applications get correct
audio/video sync, so this case is in essence tested by WMP.
I suspect that waveOutGetPosition with position.wType = TIME_MS (or values
other than TIME_SAMPLES) is bogus or un-reliable on most (all?) Pocket PC's
and Smartphone.
It would be nice to document this "bug" or "feature", i.e. to indicate that
on WinCE, only position.wType = TIME_SAMPLES is supported (and other values
of position.wType will return random results).