[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=28723

--- Comment #63 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-12-01 04:52:30 CST ---
What you describe is very interesting.  I've rarely used hw:0 myself as I
typically use a converter plugin to allow 8000x8x1.

I've hit a new variant yesterday with dmix: Given a period of 170 frames, play
Nx170 silence (N>=1), then 169 noise and wait.  Underrun is entered but the
noise is never heard.  Dmix (or the rate converter you described) is again
waiting for a full period.

This reminds me of test results on vista, where padding frames are left
unconsumed after underrun.  Not so with w7.

It means that the last milliseconds of any sound are not played in Wine using
dmix unless the app adds silence -- which is what MSDN recommends for mmdevapi.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd316756%28v=VS.85%29.aspx


I'm sorry GetPosition is not ready.  Yesterday I had a case with PulseAudio
where the first call to snd_pcm_delay after starting to play returned -5. 
GetPosition should return 0+old_samples in that case, which would need a new
variable old_samples to cumulate samples played until the last underrun (may be
valuable for MacOS too).  Second, I've had cases where PulseAudio avail_update
returned ~1.8s worth of frames, much more than the 50ms buffer_size I set.  So
computing alsa_padding as buffer_size-avail_update does not work.  I'm not
amused.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.