RFC: detecting wine drivers in the audio tests

[Robert Reif]

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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad_drivers.diff.txt
Url: http://www.winehq.org/pipermail/wine-devel/attachments/20080430/101aa38e/attachment.txt