[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 #87 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-12-15 03:48:17 CST ---
>But _near() runs the same risk as _max(), that is, it allows ALSA to give us
>too small a buffer (Bug 28282).

Do you mean?
fixme:alsa:AudioClient_Initialize ALSA buffer time is smaller than our
period time. Expect underruns. (352 < 441)
I thought this is caused by the bogus period=duration/10.  With duration/10
gone, I believe ALSA will heed our advice.

Perhaps we should enforce set_buffer_size_min = 2 * mmdevapi_period in addition
to set_buffer_near?  But I've not yet thought about the theoretical lower
limits that ensure a continuous stream.

> Other than wasting memory, what's the harm of a
>2s buffer since we limit our writes in alsa_write_data() anyway?
SW may select varying behaviour based on the hints it gets.  IIRC MSDN says
that duration is a hint that allows to select between fast & "don't care"
behaviour; XAudio2 changes behaviour when period > 10.5ms.  Perhaps PA too?
That's why I consider it important to give adequate hints.  In comment #72,
I've myself proposed changing behaviour when duration<=80ms.

>do you think they should block this patchset?
No. Mastering buffer size is another topic than mastering PA.


I can't take ownership of 0002 for as long as it contains the bogus if(period)
logic that goes against my current knowledge.  Either merge 0002 and 0004, or
perhaps wait for my 0000 patch that sets period & duration limits properly. 
The missing piece from 0000 is the exact upper limit on period and duration
sizes in exclusive mode (which do not look like what MSDN documents about
Initialize).

My yesterday buffer size tests have shown:
shared mode: duration is min. 3*periods on testbot
excl.  mode: duration is min. 8*periods!  That shows how much the MS developers
thought would be needed to provide stable output.

>get it in ASAP
This Friday's 1.3.35 would be nice.

>submit them one-per-day
I don't believe that's needed as e-mail does not guarantee ordering.  If we all
send numbered patches, the committer should apply them in order.

When that'll be done, more patches will be needed
- IAC_Stop no snd_pcm_drop (in my queue)
- alsa_period filler to ensure ALSA starts
- alsa stalling detection
- change OSS accordingly

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