http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #59 from Alexey Loukianov mooroon2@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?