Francois Gouget wrote:
You will notice the following problems:
- the test takes awfully long (>6 minutes here). It loops through the
known formats and for each of them it plays, in turn, the regular test, a test through a duplicated buffer, with a listener, etc.
- as a result of the above, a user listening to the test does not
know what to expect, which makes it hard to know whether the sound was played correctly.
The corresponding Microsoft test takes hours to complete. If time is an issue, then the test should be split up into a quick test and an exhaustive test.
Also, volume and pan tests on primary and secondary buffers is not the same thing as 3D. They just happen to be similar now because we don't support hardware acceleration yet.
Robert Reif wrote: [...]
The corresponding Microsoft test takes hours to complete.
What is this 'corresponding Microsoft test'? Do you mean that this test takes hours to complete on Windows? If that's the case it would be a sign that the test is buggy. In any case I don't see the point of having a test that takes that long to complete. Who is going to listen to a single test running for hours?
If time is an issue, then the test should be split up into a quick test and an exhaustive test.
My patch does not reduce the scope of the test in any significant way while still being much shorter to run.
Also, volume and pan tests on primary and secondary buffers is not the same thing as 3D. They just happen to be similar now because we don't support hardware acceleration yet.
Well, what I wanted is a test that only tests support for each sound format with nothing else that would interfer with that. Testing each known Microsoft format is very important because this is where we have problems today (although DirectSound seems pretty broken in Wine these days). We could split things further (format tests, volume tests, panning tests, 3D tests) but it really did not seem necessary at this point.
Francois Gouget wrote:
Robert Reif wrote: [...]
The corresponding Microsoft test takes hours to complete.
What is this 'corresponding Microsoft test'? Do you mean that this test takes hours to complete on Windows? If that's the case it would be a sign that the test is buggy. In any case I don't see the point of having a test that takes that long to complete. Who is going to listen to a single test running for hours?
Microsoft has a test suite called the "Hardware Compatibility Tests" which is used by computer manufacturers to obtain that Microsoft Windows Certified sticker on the outside of your computer. A very small part of that test suite is for Multimedia Devices and a small part of that is for the DirectSound hardware. This is the test that I was referring to that takes hours to run.
If time
is an issue, then the test should be split up into a quick test and an exhaustive test.
My patch does not reduce the scope of the test in any significant way while still being much shorter to run.
As I see it, there are two reasons for running the "interactive" tests: one is so that someone can listen to the output and verify proper operation and the other is to exercise all possible code paths. The current tests in non-interactive mode are more like API tests than functional tests.
I understand the need for a quick "Can you here me now" type test and that is something that I wish were included in the non-interactive part of the tests so at least some part of that code path always got tested.
However, we are barely scratching the surface of what can and should be tested in a more comprehensive test suite. Part of why we are not doing that now is because of the limited ability of the current DirectSound implementation. A lot of things are either missing or just don't work.
Also, volume and pan tests on primary and secondary buffers is not the same thing as 3D. They just happen to be similar now because we don't support hardware acceleration yet.
Well, what I wanted is a test that only tests support for each sound format with nothing else that would interfer with that. Testing each known Microsoft format is very important because this is where we have problems today (although DirectSound seems pretty broken in Wine these days). We could split things further (format tests, volume tests, panning tests, 3D tests) but it really did not seem necessary at this point.
Running these tests with an ALSA driver doesn't work well. They do work well with real OSS (not ALSA emulation) and a well supported sound card. Part of this problem is the quality of the sound card drivers (both OSS and ALSA) and part is because of wine's drivers.
-
Francois Gouget -
Robert Reif