[Bug 29714] mmdevapi/capture test often fails on debian testing

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=29714

Jörg Höhle <hoehle at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|download                    |source
                 CC|                            |aeikum at codeweavers.com

--- Comment #1 from Jörg Höhle <hoehle at users.sourceforge.net> 2012-01-27 05:56:10 CST ---
>capture.c:140: Test failed: GetNextPacketSize 0 vs. GCP 9
Likely that machine is fast and started capturing (very little) data.

Having GetCurrentPadding return values modulo PeriodSize is not the solution,
unless GetBufferSize is a multiple of it (when full, it'll substract 480 each
time from 23941 frames).

I think I'll make GetBufferSize always return a multiple of the buffer size,
deviating from native behaviour in shared mode, rather than weakening this test
(weaken the GetBufferSize test instead).  MSDN does not guarantee exact buffer
sizes.

However, I first want to test exclusive mode behaviour.  Also there should be a
test to see what happens with the last GetBuffer when emptying the buffer
downward from 23941 frames (better do that when stopped).


BTW, according to this year's new definition, this is not a regression.
http://www.winehq.org/pipermail/wine-devel/2012-January/093643.html

What I've done on MacOS is to let my test loop script know that e.g.
winecoreaudio render will always return 3-4 failures where winealsa returns
none.  As I explained elsewhere, I don't know how to write meaningful tests
that know that some things will fail with only one of OSS or MacOS or ALSA.

-- 
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.