[Bug 46104] winepulse-PulseAudio_Support patch cause application to hang with native dsound.dll

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Nov 9 17:38:50 CST 2018


https://bugs.winehq.org/show_bug.cgi?id=46104

--- Comment #5 from Lorenzo Ferrillo <lorenzofer at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list