The sad state of audio GetPosition

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Maarten Lankhorst wrote:

>But it's not the same, wine doesn't officially handle exclusive mode.
Eh? This is new to me!  Back in June Andrew Eikum wrote:
>These limitations might be true for exclusive mode,
>which isn't really implemented in Wine.
... which is not the same in my ears.

Andrew back in June:
>I think it would be worth having a loud FIXME
>when exclusive mode is requested, though.
Maarten today:
>Instead it might be better to just report failure and only allow shared mode.

I prefer a FIXME in exclusive non-event mode and the error in
exclusive event mode because that particular GetBuffer protocol
is not supported in the current code.
FIXME because exclusive non-event mode basically works except that
we don't know yet when exactly native delivers events.
As nobody else wrote that patch so far, I'll do.


>On windows you're not required to support exclusive mode,
>and you can disable exclusive mode in the audio control panel.
I've read that games offer it as an option but believe that all
apps will use the shared mode by default for the reason you say.
Mixing has become a commodity.


> http://msdn.microsoft.com/en-us/library/dd370844%28v=vs.85%29.aspx
>I meant an entire period then, this describes how windows handles it
What part of that document do you have in mind?
Their example uses exclusive+EVENTCALLBACK, which my test doesn't.

>my guess is that if you don't fill a period,
>you get an underrun, no matter how you handle it.
Sure.  Yet I want to know how it affects GetPosition, e.g. bug #28039
IMHO I'm free to use GetBuffer+ReleaseBuffer twice or 3x
within whatever MSDN calls a "buffer-processing period"
if it pleases me.  What matters is how much has
accumulated once the period tick occurs.

If period sizes would really matter, then the API would
provide means to obtain the period size in frames.
It does not.  Initialize takes a period in milliseconds
and MSDN does not guarantee what you actually get.
So the average app simply does not know the period size in frames.
(My tests do try to second-guess mmdevapi's exact behaviour).
Actually, mmdevapi tries to abstract away from these parameters.


BTW, a bug in MSDN:
render.c:799: Test failed: BufferSize 21846 too small for duration at rate 44100
mmdevapi appears to use not ceiling(), but floor(duration, period_frames).
The actual duration is *not* at least as large as asked for.
(For the period, it uses ceiling).

Regards,
	Jörg Höhle