[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 #46 from Alexey Loukianov <mooroon2 at mail.ru> 2011-11-11 21:53:28 CST ---
(In reply to comment #45)
> When you pump out data at fixed intervals...

Thanks for explaining, your points seems to make really big sense.

> Yet I think that a heuristic like "if near underrun, feed ALSA a little" may
> be ok, nevertheless one must carefully assess how this affects..

Yeah, but then IMO it would be more important to get xrun-free behavior at
first, regardless it would result in slightly bigger latency, and then proceed
with adding heuristics trying to shrink latency carefully testing each and
every optimizing change in code. 

(In reply to comment #44)
> Sorry for the short comment -- what I've been missing from the patches so far
> is a path for apps that don't care about short periods and buffers, e.g.
> winmm:playsound.  I.e. when an app calls mmdevapi with a large duration, ALSA
> should not be used with a 5ms period, e.g. 200 timer interrupts per second.
> 
Good point, but it would diverse winealsa.drv mmdev behavior from what is
observed on native OS. My tests seems to show that from client POV Win7 mixer
always "ticks" in 10ms, no matter the buffer size client requests. Having Wine
behaving in some other way might be perfectly OK for some cases but would cause
problems with poorly written apps that rely on this undocumented behavior. For
this optimization to work we need some other criteria except for buffer size to
proceed with long periods. Maybe best bet would be to make a judgment basing on
presence of event: we may assume that in case app wants to receive events - it
wants to minimize latency using event-driven shared mode buffer fills and react
accordingly. Real apps tests would be needed to prove if this assumption is
wrong or not.

Also, take a look into MSDN. There it is explicitly stated that for the shared
mode non-event-driven render stream the latency is only dependent on the
difference between the position where an app writes data to the buffer and the
position an audio engine reads data from the buffer. It leaves us with a tiny
period requirement no matter the buffer size :-(.

>  - GetPosition seems 30-40ms away from padding position in shared mode, but
> extremely close to padding in exclusive mode.
> I'm unsure how to explain that. 

Well, as (A) in the best case (from latency POV) the buffer for exclusive mode
is a real buffer HW DMA engine is reading from, and (B) there's no
mixer-in-the-middle - having padding to be extremely close to GetPosition is
pretty reasonable IMO for exclusive mode. You simply don't have
latency-introducing entities downstream from app to the sound hardware so
there's no reasons for padding to differ heavily from real playback position. I
assume that you're writing about non-event driven exclusive mode, as the value
of GetCurrentPadding is meaningless for event-driven exclusive mode.

> BTW, about GetPosition, did you use my patch from comment #32 or something
> else?
No, I hadn't tried to fixed Wine's GetPosition up till yesterday and had tried
to quickly hack-in my own implementation afterwards. My implementation is
pretty bogus ATM, thanks for reminding me about the existence of your WIP patch
targeting this problem.

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