Hello Robert, 2008/4/29 Robert Reif <[EMAIL PROTECTED]>: > 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
