Hello Robert,
2008/4/29 Robert Reif reif@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