Ken Thomases ken@codeweavers.com writes:
This reverts commit 6a7127bfc201ff7a218795c239d5b2571ea413d7 and part of 9f32c0d9d60662ac8e00ce5cbd4aebd4fdf8dc89.
It turns out that the issue isn't a limitation of winmm. It's just individual low-level drivers that may fail to support opening the device twice. So, there's no way to write the test (is it todo_wine or not? depends on the driver).
That's not a reason to remove it...
Alexandre Julliard wrote:
Ken Thomases ken@codeweavers.com writes:
This reverts commit 6a7127bfc201ff7a218795c239d5b2571ea413d7 and part of 9f32c0d9d60662ac8e00ce5cbd4aebd4fdf8dc89.
It turns out that the issue isn't a limitation of winmm. It's just individual low-level drivers that may fail to support opening the device twice. So, there's no way to write the test (is it todo_wine or not? depends on the driver).
That's not a reason to remove it...
The test also fails on real Windows 95 and Windows 98 (pre SE) for the same reason.
The wine audio system is patterned after the old Windows 95 implementation and behaves just like it. Applications are given access to the low level audio drivers so the audio drivers determine the audio system behavior.
Getting this test to always pass on wine would require moving the whole audio system over to a virtualized hardware model like Windows 98 SE and later did. However that will not fix the fact that this test will almost always fail on old versions of Windows.
The test is bogus unless you look at the OS version. The test will always pass on Windows 98 SE and up and will most likley fail on all Windows versions prior to 98 SE depending on what hardware and drivers are used.
-
Alexandre Julliard -
Robert Reif