Split the dsound test

[Robert Reif]

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.