[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 #59 from Alexey Loukianov <mooroon2 at mail.ru> 2011-11-30 06:21:08 CST ---
(In reply to comment #58)
> >when I request 20ms buffer for 44100Hz stream I got 896 samples buffer
> I conclude that you have an Intel HDA.  That uses no 10ms period rather than a
> 10.1587ms one with 448 frames.  IOW, you need to repeat your tests (441->448)!

Actually it isn't Intel HSA, it's rather Conexant HDA codec sitting on HDA-bus.
Nevertheless reported default period is really 448f. As for repeating tests -
actually I've done testing with chunk_size = buffer_size >> 1, which is exactly
448f for 896f buffer.

> .. yet the following code predicts non-HDA engines... 
> (lisp black magic follows)

Oh my, there are some programming languages out there that I'm not comfortable
with (IOW don't like them and/or find their syntax/concepts too confising).
Lisp is one of those, other are prolog, perl, python :-). Would have to smoke
in common list specs to decypher that cryptic construct to something that looks
like more traditional-math like.

> It would be good if you could find the correct formula for exclusive
> mode with Intel HDA.

I hadn't even touched the exclusive mode in my tests yet. And I'm a bit curious
are there any real-world apps out in the wild which use exclusive mode?

> Well, Alexey even complains about 5ms :-)

That's not complaints, it just the observation of the behavior that differs
when running testcase on Win7 vs. Wine :-).

> Alexey's comment is a bit troubling.  If there was a 28ms lag while
> feeding data, I'd expect GetPosition to slowly reach sum_written
> within 28ms after feeding ends.

Yeah, that's what exactly happens.

> He seems to say that GetPosition is bumped to sum_written as
> soon as there's no more data to feed.  This would be important
> behaviour to mimic.

No-no-no, sorry for not being clear in my original comment. With both Wine and
Win7 I've got devposition steadily increasing up to but no more than the amount
of data I had pumped out to the audio engine. If I stop pumping the data out
and start polling the value returned by IAudioClock_GetPosition - I get devpos
steadily approaching the samples_written count and stay there constantly until
I pump out some more data. Note, that this behavior is not the case for the
devpost value returned by IAudioClock2_GetDevicePosition - it is totally
different beast affected by devpos backwards jumps to 0 on hardware underruns
and maybe some other circumstances I hadn't discovered yet.

> ---- Alternatives
> ...

Hmm, your pseudocode looks promising but I have a couple of questions
concerning it:
1. Does it really matters would we write out data on each event or not if we
still would be receiving timer callbacks every 10ms? The only real possible
benefit I see is that we would kind-a be "protected" from "skips" in output
stream when the system wouldn't be able to schedule out timer callback timely
due to something like paging or executing some other high-prio thread. That's a
good reason on its own but only in case actual implementation wouldn't be
excessively complicated.

2. What is "gcp" here? GetCurrentPadding? held_frames? Something else?

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