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@yodull tests $ pwd /var/src/wine/dlls/winmm/tests greg@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.