Prev: DirectX SDK error in C++ program
Next: What is really the format of the RT_FONTDIR, FontDir resource?
From: Bob Masta on 15 Sep 2009 09:06
This is to report a bug in waveInGetPosition and
waveOutGetPosition, which appears in all 32-bit
versions of XP. ( XP-64 not tested.) It does not
appear in Vista nor in Win95. Other versions of
Windows have not been tested.

The bug has to do with the way the sample count
wraps. Assume you have defined an MMTIME structure
called OutTime and specified OutTime.wType =
TIME_SAMPLES. After invoking waveOutGetPosition,
OutTime.u.sample should hold the count of output
samples since the current waveOut process began.
Since this is a 32-bit value, it is expected to
wrap back to zero after 0xFFFFFFFFh, which is
24.855 hours at 48000 samples per second.

However, on XP systems it actually wraps after
0x07FFFFFF samples (46.6 minutes) for stereo
waveOut, or 0x0FFFFFFF samples (93.2 minutes) for
mono. waveInGetPosition behaves exactly the same
way.

This problem was noted on 4 different XP systems.
To verify that it was not a driver problem, the
same USB Audio device (with built-in driver) was
tested on XP and Vista systems, and the problem
only appeared on XP.

To handle this problem, you will need to keep a
working copy of the position value. (You may
already have one to handle the expected 0xFFFFFFFF
wrap.) When you read a new position value, mask
it with 0x07FFFFFF, and also mask a temporary
"copy of the working copy" with the same. If the
masked copy is above the new value, there has been
a wrap since the last reading... in that case, add
0x08000000 to the working copy. When that
overflows after 0xFFFFFFFF hours, increment a
value that will hold the high bits of the
position, as you may already do. (The 64-bit
total will be good for 12 million years.)

Best regards,




Bob Masta

DAQARTA v4.51
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
FREE Signal Generator
Science with your sound card!
From: vinaykabadi on 18 Sep 2009 14:34
On Sep 15, 6:06 am, N0S...(a)daqarta.com (Bob Masta) wrote:
> This is to report a bug in waveInGetPosition and
> waveOutGetPosition, which appears in all 32-bit
> versions of XP. ( XP-64 not tested.) It does not
> appear in Vista nor in Win95.  Other versions of
> Windows have not been tested.
>
> The bug has to do with the way the sample count
> wraps. Assume you have defined an MMTIME structure
> called OutTime and specified OutTime.wType =
> TIME_SAMPLES. After invoking waveOutGetPosition,
> OutTime.u.sample should hold the count of output
> samples since the current waveOut process began.
> Since this is a 32-bit value, it is expected to
> wrap back to zero after 0xFFFFFFFFh, which is
> 24.855 hours at 48000 samples per second.
>
> However, on XP systems it actually wraps after
> 0x07FFFFFF samples (46.6 minutes) for stereo
> waveOut, or 0x0FFFFFFF samples (93.2 minutes) for
> mono.  waveInGetPosition behaves exactly the same
> way.
>
> This problem was noted on 4 different XP systems.
> To verify that it was not a driver problem, the
> same USB Audio device (with built-in driver) was
> tested on XP and Vista systems, and the problem
> only appeared on XP.
>
> To handle this problem, you will need to keep a
> working copy of the position value.  (You may
> already have one to handle the expected 0xFFFFFFFF
> wrap.)  When you read a new position value, mask
> it with 0x07FFFFFF, and also mask a temporary
> "copy of the working copy" with the same. If the
> masked copy is above the new value, there has been
> a wrap since the last reading... in that case, add
> 0x08000000 to the working copy.  When that
> overflows after 0xFFFFFFFF hours, increment a
> value that will hold the high bits of the
> position, as you may already do.  (The 64-bit
> total will be good for 12 million years.)
>
> Best regards,
>
> Bob Masta
>
>               DAQARTA  v4.51
>    Data AcQuisition And Real-Time Analysis
>              www.daqarta.com
> Scope, Spectrum, Spectrogram, Sound Level Meter
>            FREE Signal Generator
>         Science with your sound card!

Hi Bob,

One of my discoveries too, in DSound GetCurrentPosition of
LPDIRECTSOUNDBUFFER8 and LPDIRECTSOUNDCAPTUREBUFFER8, we get the read,
write and play cursor much random than the accpected ones. Actually
the rate of play and capture itself could be volatile and hence the
cursor positions looks wrong

Regards
Vinay
 | 
Pages: 1
Prev: DirectX SDK error in C++ program
Next: What is really the format of the RT_FONTDIR, FontDir resource?