Robert Reif wrote:
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 think this was discussed before in regards to d3d. Except not in the sense of bugs but differences between how d3d behaves for Wine and for some applications. AKA workarounds for applications. In some way that can be considered bugs.
I'm not sure how much of that is going on with sound drivers. And there are might not be an easy way to find out.
I think in this particular case where it's clear what it is a bug (most other drivers do the right thing and in agreement with MSDN) then it might be time for "todo_windows".
Vitaliy. There agreement was that drivers have specific workarounds for specific programs.