On 08/22/2011 02:13 PM, joerg-cyril.hoe...@t-systems.com wrote:
> Hi,
>
> These exclusive mode test failures look like nothing:
> render.c:1086: Test failed: GetCurrentPadding returned 576, should be 0
> render.c:1092: Test failed: Position 90720 at end vs. 91296 played frames
> but they made me completely rework my model of how mmdevapi works.
>
> 91296 = 90720 + 576 remainder
> 90720 = 720 * 126
> 720 = 15ms period at 48000 frames/s
>
> It looks like only a multiple of period_size frames are rendered.
> There are also test runs which end with GCP > period_size despite underrun
>
> Only Vista and w2k8 present these 2 errors. w2k8R2 and w7 only
> present the second one. In shared mode, GetCurrentPadding (GCP)
> returns 0 and GetPosition returns all submitted ("played") frames.
> What happened?
>
> Possible explanations:
> Vista + w2k8 exclusive mode:
> a) Bug in native that forgets to account for sub-period_size data. Or
> b) Play only multiples of period size. Wait until period_size data
> accumulates before sending the next packet.
Have to go with this one, exclusive mode wants you to fill the entire buffer at
the same time..
> c) other...
>
> w2k8R2 + w7 exclusive mode:
> a) Bug in native that sets GCP to 0 (like in shared mode). Or
> b) At each period tick, only play data if a full period is available.
> Drop partially filled buffers (explains padding = 0) instead of
> playing them much later when the buffer fills up (no ghost sounds).
> c) Bug in native that forgets to increment Position yet plays data.
> d) other...
If I look at msdn, exclusive mode wants you to fill the entire buffer in 1 go,
doing partial data doesn't make sense, and it wouldn't surprise me if that's
why it drops things..
> shared mode:
> a) At each 10ms period tick, mix a period_size of all streams that
> provided a full period of data. Ignore other streams yet always
> decrement GetCurrentPadding and sum played/ignored frames.
> b) At each 10ms period tick, mix all streams. Handle streams with
> padding < period_size as follows:
> - if previous frame was full, mix at beginning of buffer (trailer)
> - otherwise mix at end (expect beginning of next sound)
> c) At each 10ms period tick, mix all streams, padding streams with
> less than period_size frames with silence (i.e. mix at beginning).
> d) other...
> If I were MS, I'd implement heuristic b).
>
> This is all unlike what Wine does...
I'm inclined to believe it's C
> I'll probably write audible audio tests in the next few weeks to be
> able to test what native does (e.g. emit a short beep < period size
> every few ms and listen to what happens).
>
> Regards,
> Jörg Höhle
>
>