trouble with winmm/tests and winearts.drv

[Francois Gouget]

On Mon, 20 Jan 2003, Greg Turner wrote:

> Linux 2.5.59 seems to have broken my ALSA.  Rather than worry about
> fixing it, I guessed that "just waiting" will fix the problem as future
> releases of either gentoo or linux would probably eventually resolve
> whatever conflict I have.
>
> So, temporarily, I have put aRTS into "OSS/threaded" mode.  This
> successfully uses ALSA's OSS emulation.  Then, I activated winearts.drv
> to use that instead of my usual ALSA.
>
> Now, when I run make test, I get a failure.  Here's some output:
>
> greg at yodull tests $ pwd
> /var/src/wine/dlls/winmm/tests
> greg at yodull tests $ wine winmm_test.exe.so wave
> mcop warning: user defined signal handler found for SIG_PIPE, overriding
> err:wave:ARTS_WaveInit arts_init() failed (-1)
> wave.c:182:found 10 WaveOut devices
> wave.c:206:  0: "" 0.0 (0:0): channels=0 formats=0000 support=0000
> wave.c:220:Testing invalid 2MHz format
> wave.c:229: Test failed: opening the device at 2MHz should fail 0: rc=4
> wave.c:248: Test failed: opening the device at 2MHz should fail 0: rc=4
[...]
> The code from winearts doesn't seem to check the frequency at all.
> Could this be because it's legitimately supported under aRTS?

I very much doubt that any soundcard could support a 2MHz signal.  I
guess it could potentially be downsampled to something more reasonable
but that would be strange.


> Either the test is broken, or the driver is broken.  I don't know which
> fix would be the correct one, kill the test, or add a minimum frequency
> in the driver...

Is there any way to find out what's the maximum supported sampling rate
with aRts? If yes, then adding such a check would be the best solution.
If not we can either refuse sampling rates above some arbitrary limit
(e.g. 100kHz as in Directsound), or change the winmm test.

The goal of that test was to check the error code that is returned when
an invalid sampling rate is provided (since it was incorrect in the
wineoss driver initially). If we decide that the winearts driver should
calim to support all sampling rate up to +infinity, then the test will
have to be changed. We could try going down and see if 1Hz or 0Hz would
do what we want (I believe the sampling rate is unsigned to negative
sampling rates are ruled out).


> Also: It seems odd when test behavior changes due to changes in
> ~/.wine/config and/or the installed wine.  This happened for my RPC
> tests, although I was able to work around it.  Shouldn't the tests
> always run the same way?  Is it really acceptable to test things that
> may depend on the user's config and/or wine installation particulars?

The test should not fail just because you happen to have a different bit
depth or something like that. However, here it is exercising a different
part of the Wine code selected by a config option so depending on the
bugs in that part it may or may not fail.


-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
                            1 + e ^ ( i * pi ) = 0