[wdmaudiodev] Re: IMiniportWaveRTStream::GetPosition 32-bit wraparound
- From: Ken Cooper <Ken.Cooper@xxxxxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Fri, 7 Dec 2007 11:21:32 -0800
The code in the WDK should mod with the buffer size as you suggest. As it
turns out, the code in the WaveRT port driver in PortCls.sys does this mod on
the positions returned by the miniport's GetPosition call. With that in mind,
it doesn't really matter whether or not you report linear or cyclic position
values, though cyclic is consistant with the spec and consistant with the
devices (HD Audio) that support position register mapping.
As for the question on PlayOffset versus WriteOffset, I responded some time
back stating that for WaveRT drivers you can just set the WriteOffset to equal
the PlayOffset. For WaveRT drivers, the audio stack doesn't use the
WriteOffset value returned from the GetPosition call. The WriteOffset is kept
track of at a higher level.
Ken
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff Pages
Sent: Tuesday, November 06, 2007 9:29 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: IMiniportWaveRTStream::GetPosition 32-bit wraparound
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/
******************
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:
