http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #259 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-03 10:27:33 CST --- In bug #9358, comment #21, Maarten Lankhorst explained that primary.c:DSOUND_fraglen is a hack to second-guess the period size as "the current driver model doesn't" tell. This is no more the case. The hack should be removed. The period size is IAudioClient_GetDevicePeriod. With mmdevapi, DSound receives one event every such default period and that's the quantity that it should mix (currently winealsa/oss: 10ms, winecoreaudio: 20ms). IOW, it should act like the XAudio2 in bug #28723 -- ouch! I don't know when DSound is allowed to send more data in advance.
BTW, in bug #1631, comment #129 Maarten Lankhorst talks about trouble with <100ms buffers. 4 years later, I've doubts we won't face trouble with 10ms periods and 40ms buffers. We can't expect machines that much faster and reliable, see bug #28723, comment #51 and 61.
I'm not familiar with DSound, but why another buffer? Why not GetCurrentPadding & GetBuffer, then mix into that one, eventually ReleaseBuffer (may release a smaller number of frames)? Sadly, DSound's primary buffer may match HW well, but not mmdevapi's buffer model...