[wdmaudiodev] Re: IMiniportWaveRTStream::GetPosition 32-bit wraparound
- From: "Jeff Pages" <jeff@xxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Wed, 7 Nov 2007 16:29:25 +1100
I don't have an answer but I do have a related question.
The GetPosition function is supposed to set the PlayOffset and the
WriteOffset values. Now the driver knows what the PlayOffset is but the
WriteOffset, the way it's defined in the WaveRT White Paper, is the point at
which the client will next write and the driver has no knowledge of that. I
queried this a few months back and was told to just set WriteOffset to the
same value as PlayOffset, but I've noticed in the AC97 WaveRT sample in the
latest WDK it says "the WriteOffset is PlayOffset + FIFO size" and the
expression used for that is:
Position->WriteOffset = Position->PlayOffset + NumberOfChannels * 2 * 8;
This means that, at times, WriteOffset will go beyond the bounds of the
buffer. Shouldn't this be modulo the buffer size, or is Matt right and the
values returned should be cumulative from the time playback or capture
starts?
Also, what does Windows do with the WriteOffset value returned?
Jeff
----- Original Message -----
From: "Matt Gonzalez" <matt@xxxxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Wednesday, November 07, 2007 12:58 PM
Subject: [wdmaudiodev] IMiniportWaveRTStream::GetPosition 32-bit wraparound
We have a problem with our Wave RT driver. I think I fixed it, but it
appears that doing so requires me to violate the spec.
The problem is that audio playback starts to break up after about three
quarters of an hour. In fact, it turns out that it breaks up at the point
where a 32 bit integer would roll over. The device is playing back 48 kHz
8 channel 32-bit audio; doing the math means that a 32-bit integer would
overflow at around 46.6 minutes. Running the audio clock faster by
syncing to word clock causes the breakup to occur earlier proportionate to
the increase in the audio clock.
My device does not support a map-able position register, so my driver
instead relies on the GetPosition call. The documentation states
"Positions are specified as byte offsets from the beginning of the cyclic
buffer"; it does not say so explicitly, but the wording suggests that the
position should be no greater than the size of the cyclic buffer, similar
to the position register. However if I implement my driver such that it
returns the position modulo the buffer size, I see the above problem.
If I change my driver to return a constantly increasing 64-bit position,
everything seems to be fine. I was able to play for well over an hour
with no problems.
So am I just misreading the specification? Is my solution in fact
correct?
Thanks,
Matt
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
