[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
wine-bugs at winehq.org
Wed Nov 30 06:21:08 CST 2011
--- 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
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
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.
More information about the wine-bugs