mmdevapi buffering

Andrew Eikum aeikum at codeweavers.com
Wed Jun 1 08:25:47 CDT 2011


On 06/01/2011 07:33 AM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> The problematic situation is when avail is small, as the following sleep for half a
> buffer size in MSDN's example will inevitably produce an xrun.
> So what actually is the buffer size and how does GetCurrentPadding behave?
>
> I don't expect MSDN's example to be fundamentally flawed.  IMHO, they
> designed their API such that it is the typical use case.
> I believe that multiple buffers (of size GetBufferSize) are
> involved (much like ALSA's periods) and that GetBuffer switches among
> them -- exactly like they say about the exclusive mode ping pong.

I don't think I understand your objection. I have been thinking of the 
buffer as a FIFO queue with a size limit. Then, GetCurrentPadding() 
returns "write - read" and GetBufferSize() returns the queue size limit. 
As far as I can tell, this is entirely consistent with how Windows 
behaves. You can especially see this with the GetBuffer() failure tests 
(see <dlls/mmdevapi/tests/render.c:509> for example).

What behavior do you think Wine is going to do wrong because of this model?

Thanks,
Andrew



More information about the wine-devel mailing list