Hi,
because of bug #27087, I had a look at the emerging mmdevapi code. Actually, it's the first time I read its documentation on MSDN. Here are a few comments of mine while reading the code.
The handling of duration (-> buffer size) in winealsa.drv/mmdevdrv.c:AudioClient_Initialize does not perform enough validation. MSDN explicitly acknowledges that it could be 0. I believe it should be related to ALSA's buffer, or a minimum of something like 2*period_size. Or perhaps even 3*period size.
IIRC MSDN also documents a maximum of 2s for renderer and 0.5 for capture.
AudioRenderClient_ReleaseBuffer does not check that written_frames is what GetBuffer returned. Use with AUDCLNT_BUFFERFLAGS_SILENT and you'll have memcpy overwrite arbitrary amounts of memory. MSDN says: AUDCLNT_E_INVALID_SIZE
I believe Wine should currently include if (AUDCLNT_STREAMFLAGS_EVENTCALLBACK && SHAREMODE_EXCLUSIVE) { FIXME("unsupported") & return E_ } because none of the buffer allocation and parameter checking specific to that mode that MSDN mentions in Initialize is implemented.
When it (the ping pong buffer logic) will be implemented, some better logic to trigger SetEvent() will probably be needed, because I'm unsure whether CreateTimerQueueTimer() provides the required stability over time and possibly ignores a laptop's suspend/resume cycle or xruns. In exclusive mode, reception of an event is a guarantee that GetBuffer(GetBufferSize frames) will succeed.
I suggest the values returned by AudioClient_GetDevicePeriod be adjusted to match what test.winehq shows. 10ms/3ms makes some sense, 10ms is mentioned a lot in MSDN and blogs. 3ms is small yet has a chance to work without glitch with MSDN's exclusive mode example.
I can't remember seeing input validation of broken avgbytes and blockalign in the WAVEFORMAT parameter. I showed some tests some month ago that prove that unlike Wine, winmm is not disturbed by bad values. How does mmdevapi react to them?
Regards, Jörg Höhle