[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 #27 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-11-04 08:03:11 CDT ---
BTW, does the app use exclusive or shared mode?
GetCurrentPadding jumps by 10ms deltas in shared mode instead of decreasing
linearly over time (the latter is what *most* exclusive drivers do).
Your *out = This->held_frames; is not unlike that.

If you play with padding, I encourage you to run my GetPosition tests, see bug
#27937 (you'll also find updated versions in testbot from time to time).

I've been running tests from time to time to investigate whether
GetCurrentPadding in exclusive mode is conservative or not, i.e. whether it
returns positions ahead or not of the "true" play position.  That's not easy to
evaluate when doing remote tests only.

Basically, Wine ought to be able to play a 10ms period with buffer size = 2x
period.  2x period is exactly what exclusive callback mode wants, and native
can do that.

 - DSound needs to use callback event mode and be synchronised with mmdevapi.
MS is right when they say that event mode is better when time is critical.
  Looking at dsound, I can see how it gave MS ideas for the design of mmdevapi
and its mixer.  Wine's mixer in dsound should act as if it were mmdevapi's
mixer.
 So when the event triggers, there's at least 10ms free, the dsound mixer fills
that and sends it off to mmdevapi.

 - Ideally (future enhancement), winealsa would use poll() to be woken up when
the buffer drains instead of using a periodic timer. SIGIO is not the way to
go.

 - Some ALSA period control when timing is tight (how to determine when, base
it on duration <= 50ms?).  Alsa may not start when given less samples than
period_size, see bug #27087, comment #10.

>Buffer size of 11ms - do you mean the "duration"
Yes

>we need to pass audio data from local buffer to the ALSA as soon
>as we receive it. Waiting for next timer event to pump out data
>leads to 100% underrun.
This should be a last resort as it has its own problems.  Consider how native's
mixer (presumably) works without that trick, it operates at a fixed rate,
that's all (but as I've explained before, it would conceivably work even with
11ms duration).

BTW, I've trouble understanding both .pdf, It's not entirely clear what the X
and Y directions are.

-- 
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.