2009/11/9 Joerg-Cyril.Hoehle@t-systems.com:
Reece,
I think we reached agreement on: a) Tests should "usually" succeed. b) machines without sound are usual (e.g. in virtual server env.). c) I'll modify the MCI tests to succeed on machines without sound. But for some other points, I've trouble following you.
Yes.
The relevant question becomes: when is a configuration unusual? When can it be ignored for the purpose of Wine and when is it relevant?
Answer: no configuration is unusual.
Huh?
You asked "when is a configuration unusual?" That is, are the following unusual: 1/ using a non-English locale (e.g. German or Polish); 2/ using a non-Western locale (e.g. Chinese or Japanese); 3/ using classic theme in XP or later; 4/ using 120DPI or higher; 5/ using a high-contrast theme; 6/ not having DirectX installed; 7/ having a Windows install on a drive other than C:\ 8/ ...
My point is that none of these (and other configurations/setups in Windows) should be considered unusual. They may (or may not) be the default, but they are possible.
From the perspective of Wine (and the Wine tests), if it is possible
in Windows (on VMware or natively) then it should be handled properly in the tests and not fail the tests.
The point is, if the machine has a broken soundcard (or in Wine does not have an available sound driver, or is broken due to PulseAudio on Ubuntu), the tests should still pass (or be skipped) as is appropriate.
This seems wrong (in general) to me, even though Paul somehow expresses an opinion similar to yours. I say you cannot write a program meant to run in a completely unknown environment, doing comprehensive tests and not stumbling upon strange behaviour.
Write the tests initially for the known valid environments, then fix up issues as they are seen on test.winehq.org (for example, if some of the comctl32/user32 tests fail because they are run in 120DPI instead of 96DPI).
You cannot cater for a completely unknown environment, but those on test.winehq.org are not unknown.
Also, it is not feasible to always do comprehensive tests (e.g. on Win9x when *W functions are not present). The point is to do what you can in those cases.
The program is specifically designed to detect and flag deviant behaviour. All that can be achieved in a program is to be prepared for a known set of scenarios (a broken soundcard is such a scenerio), aka. use-case. Outside these known use-cases, the tests throw an error. Otherwise there's no point in ok() at all.
You have a set of defined behaviour for the mci API when there is a sound card present. Good -- the tests should cover that.
You also have a set of defined behaviour for the mci API when a sound card/driver is not present. Good -- the tests should handle this (e.g. by defining the set of valid return values).
I agree that for the known use-cases (these explicitly include configurations without sound), the tests should succeed.
Yes.
What can be done is what you say:
If we find that other situations need correcting (due to failing tests), they can be looked at then.
... then decide whether the cause of the failing test is "unusual" or not.
No -- look at *why* the test is failing. This will either be that the test is doing something wrong (e.g. not creating a test file), or that it is not covering a valid situation.
The cause being "unusual" or not has no relevance. Either the test is wrong, or Windows is broken.
The point I am making is that: 1. The error and skip statements are saying the same thing; 2. But the skip message is misleading.
Indeed, sorry for that. There's a dependency. The tests depend on record working to generate the file to be played, instead of including one in git. So they fail to test machines that can play but not record.
Sure.
Obviously I'll have to do something else in the yet to be written MIDI tests.
BTW, this raises the question whether Wine should include a tiny wave file for completeness. Invoking the MCI Sound command always plays some sound.
Is it possible to generate the wav file programatically, without using the record functionality?
If I have counted the offsets correctly 275 is MCIERR_DEVICE_NOT_READY, *not* that tempfile.wav was not found.
Wrong. 275 - 256 is 19, which you look up in mmsystem.h: #define MCIERR_FILE_NOT_FOUND (MCIERR_BASE + 19)
Ah yes.
default: ok(!err, "mciSendString('open') failed, expected NOERROR, got %s", dbg_mcierr(err)); }
In the default case, if (err) you must return (with or without skip message). You cannot continue if open fails. So it summarizes to: if (err) { /* list of situations that were analysed as "usual": */ ok(err=FILE_NOT_FOUND || err==MCIERR_CANNOT_LOAD_DRIVER || err==xyz ...); skip("Cannot test playback, cause %s",dbg_mcierr(err)); return }
case MCIERR_CANNOT_LOAD_DRIVER: 2. sound is not present on the system.
Perhaps there's a misconception? That's not how MS-Windows systems without sound drivers present themselves. Ge's, Paul's and my father in law's machines all include the MCI (and waveaudio.dll etc.). It's only at WAVE_Open time that failure is detected, e.g. Cue, Record or Play, and the error is MCIERR_WAVE_INPUTSUNSUITABLE for instance. (That's not entirely true, it does not explain the setformat pcm failure). I.e. no mciwave present at all so far is an "unusual" situation, and generates an error.
In the example I gave, don't look at the exact error codes -- look more at the situations (tempfile.wav does not exist, sound not available).
Also,
if (err==MCIERR_FILE_NOT_FOUND || err==...) { skip("Cannot test playback (err=%s)",dbg_mcierr(err)); return; } ok(!err, ...);
The point here is that tempfile.wav not existing, sound not available, or a broken sound driver should not cause the ok line to fail. These are valid situations that mean that the playback tests cannot be run.
Now, arguably the tests should be modified so that tempfile.wav always exist. This would then address a chunk of the test failures that are happening on all machines at present.
IIUC, that file is being generated through the record API of mci? Isn't there a way to programatically create the WAV/PCM data through the use of math.h functions?
- Reece