[PATCH 2/2] winealsa: Fix AudioCaptureClient Get/ReleaseBuffer protocol.

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

Hi,

[Please withhold this patch. Winmm is not ready yet,
 despite passing all tests.]

You'll find my capture tests in testbot job #16332
http://testbot.winehq.org/JobDetails.pl?Key=16332

The surprising news is that (in shared mode), GetBuffer
never returns more than a period worth of data.
GetCurrentPadding can return much larger values.

With that patch in place, winealsa produces almost the same
test results on my mmdevapi capture tests as a w7 machine
-- modulo the few todo_wine.

The winmm and dsound tests also pass, yet perhaps this period
size change may introduce regressions, because neither Wine's
dsound nor winmm have been reviewed w.r.t. the new behavior.

For instance, winmm/waveform.c: WID_PullData ignores AUDCLNT_S_BUFFER_EMPTY
-- it won't trigger if(FAILED) and stop the loop.
Hmm, looking at PullData I see that a patch to winmm is needed ASAP.
(Consider what happens when GetCurrentPadding is not a multiple of the
period size or how to handle winmm packets that are only partially filled).


I have a similar patch for winecoreaudio, cf. bug #29274.  However,
there must be a bug somewhere else, as GetBuffer never returns any data.
Wine even dies hard (100% CPU on both cores) when running the capture2
tests.  I'll not submit the winecoreaudio capture patch until
that is solved.

Oh my, all I wanted is to simply fix the Get/ReleaseBuffer protocol
(i.e. the return values).

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-winealsa-Fix-AudioCaptureClient-Get-ReleaseBuffer-p.patch
Type: application/octet-stream
Size: 4489 bytes
Desc: 0002-winealsa-Fix-AudioCaptureClient-Get-ReleaseBuffer-p.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20120109/c5468bca/attachment.obj>