RFC: detecting wine drivers in the audio tests

[Maarten Lankhorst]

Hello Robert,

2008/4/29 Robert Reif <reif at earthlink.net>:
> The returned result of some audio functions on windows may be inconsistent
> because a driver may actually supply the returned value.
>
>  This presents a problem for the wine regression tests because a buggy
> driver may return an unexpected result which causes the test to fail.  One
> way around this is to accept known failures as OK but that reduces the
> usefulness of the test for wine because it may allow wine bugs to slip in.
> I'm proposing the we determine if we are running on wine by defining a wine
> manufactures id and checking for that id in the test.  If a wine driver is
> found, don't accept a failure as OK.  The returned result should be well
> defined and any failure is unacceptable.  However, if the driver is not a
> wine driver and there are known buggy windows drivers that return specific
> errors, we can check for that and not fail the test.  This should be easier
> than maintaining a database of known broken drivers and black listing them.
>
>  I am concerned that requiring 100% wine regression test success on windows
> is not practical when there are broken windows drivers out there.  Accepting
> the failures as success is not good for wine because it may allow buggy wine
> drivers to also pass.  I think we should hold wine audio drivers to higher
> standards than the typical audio card manufacture.
>
>  I am suppling a minimal patch to the alsa driver and a single wave test to
> illustrate this concept.  I hope this allows valid tests to remain in spite
> of buggy windows drivers.
I don't know, the general idea is that whatever windows lets you do is
fine for wine, so I'm not 100% sure that testing for this is a good
idea, because it means in border cases windows programs can't rely on
those to return a correct or incorrect value either.

By the way you also used a C++ style comment, wine doesn't allow that.

Cheers,
Maarten