https://bugs.winehq.org/show_bug.cgi?id=46104
--- Comment #5 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 62761 --> https://bugs.winehq.org/attachment.cgi?id=62761 Tentative patch
Ok, I was able to investigate more. Native dsound.dll request a Buffer (using AudioRenderClient_GetBuffer) with NumFramesRequested 2. After writing to it, it's released. This is were things start to differ. Without the patchset then dsound request againg the position, and the AudioClock_GetPosition return 4. Then the audio stream is stopped, and the game that is using dsound start the video playback. This seems actually consistent with the MSDN specifications.
With the patchset instead, AudioClock_GetPosition it's returing 0 even after having requested and released a buffer with NumFramesRequested 2.
The issue seems the fact that in the AudioClock_GetPosition if the current position (getted from the current_clock var subtracted by the held_bytes), is setted to 0 if the position is minor then the period.
I attached a patch that allow callers to see the actual stream position, in this case. I run the mmdevapi testcase for render and it succeed. With this patch applyied the game start and it's almost playable, but there is a bit of cracking sound from Bug 45623, and also the audio seems to be a little late for one second (But this seem to be present also without the entire winepulse-PulseAudio_Support, even if a lesser way).
I'm wondering what's the rationale between setting *pos to 0 in that case.