mciseq: Prevent busy-wait while paused.

Hi,

any comment on that patch? It's currently the bottommost in
source.winehq.org/patches hence may fall into the bitbucket anytime.

I had noticed that the MCI MIDI player would busy loop while paused
because of a while(xyz) ; statement therein.

Test it using these MCI commands
open c:\data\foo.mid alias m
play m
pause m

So I simply added a Sleep() and wrote:
> 7 ms is arbitrary. It allows to sleep well yet be responsive enough
> so the app doesn't wait too long should the next command be MCI_Stop.
> For the ear, an even larger sleep would be good enough.

Sleep is a sort of stop gap until someone invents a
notification/setEvent/Resume patch or whatever would be TRT.

Regards,
 Jörg Höhle

[Maarten Lankhorst]

Hi Joerg,

2010/4/15  :
> Hi,
>
> any comment on that patch? It's currently the bottommost in
> source.winehq.org/patches hence may fall into the bitbucket anytime.
>
> I had noticed that the MCI MIDI player would busy loop while paused
> because of a while(xyz) ; statement therein.
>
> Test it using these MCI commands
> open c:\data\foo.mid alias m
> play m
> pause m
>
> So I simply added a Sleep() and wrote:
> > 7 ms is arbitrary. It allows to sleep well yet be responsive enough
> > so the app doesn't wait too long should the next command be MCI_Stop.
> > For the ear, an even larger sleep would be good enough.

It would be better to signal an event object to wake up from sleep.

Cheers,
Maarten

winmm: Remove timeGetTime.

Hi,

Maarten recently mapped winmm:timeGetTime to kernel32.GetTickCount
This rang a bell and now I found again the article where I read about it:

http://blogs.msdn.com/larryosterman/archive/2009/09/02/what-s-the-difference...

"So why are all these multimedia APIs using timeGetTime and not GetTickCount
since the two APIs apparently return the same value? ...
The answer is that they don’t."

I cannot judge whether what's described there applies to Wine's timing.
However the listed timings prove both values are different.

FWIW, I've determined long ago that timer increments in MS suffer
from a 15.625ms granularity.  This affects almost all applications
in MS-Windows.  For instance, JMeter(Java) always returns times that
are multiple of this value, plus/minus rounding.  It will tell you
jobs took 15, 16, 31, 32, 46 or 47ms etc.  Never 5, 12, 26 or 30ms!
You can't use it to time short jobs.
I've seen the same values in many other apps (not just Java) and
several versions of MS-Windows.
Heck, 46 and 47ms are even shown in the above URL in the dTicks column
(as well as the next pair: 62 and 63ms).

Whatever you measure, you'll encounter this 15.625ms increment.
Presumably, the high performance counters are not affected.  But
few apps seem to use these.

What's 15.625ms?  Exactly 64 ticks per second
... and the linearisation of all returned values.

If you GetTickCount something that truly takes 29ms multiple times,
you'll observe 31/32 deltas much more often than 15/16. (As the article
says: "note that the deltas average to 55ms").

Regards,
 Jörg Höhle

winemmaudio.drv: Add support for wavein

Maarten,

I looked at part of these two patches about winmm->mmdevapi bridge
and they looked very clean to me.

+    caps.dwSupport = WAVECAPS_SAMPLEACCURATE|WAVECAPS_LRVOLUME|WAVECAPS_DIRECTSOUND;
AFAIK WAVECAPS_LRVOLUME never occurs alone, _VOLUME is missing.

+    if (wfx->wFormatTag == WAVE_FORMAT_EXTENSIBLE)
+        extra = sizeof(WAVEFORMATEXTENSIBLE)-sizeof(WAVEFORMATEX);
+    else
+        extra = 0;
This seems to depend on some assumption that IAudioClient_IsFormatSupported
will reject anything but WAVE_FORMAT_EXTENSIBLE and WAVE_FORMAT_PCM.
You may not want to not depend on this.

+        wwo->wfx->nBlockAlign = wfx->nChannels*wfx->wBitsPerSample/8;
+        wwo->wfx->nAvgBytesPerSec = wfx->nSamplesPerSec*wfx->nBlockAlign;
This only applies to WAVE_FORMAT_PCM (and PCM encapsulated in EXTENSIBLE).

I've attached tests that you may want to try out.  I've never
submitted them because they cause weird behaviour in Wine
(both incorrect duration and frequencies).
On native, they work fine, which shows that native ignores broken
nAvgBytesPerSec and nBlockAlign.

How does your OpenAL bridge behave with them?
You need WINETEST_INTERACTIVE=1 because it's essential to hear the sound.

Regards,
    Jörg Höhle