No subject

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. =A0I 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. =A0Otherwise
> 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:
>> =A01. =A0The error and skip statements are saying the same thing;
>> =A02. =A0But the skip message is misleading.
> Indeed, sorry for that.
> There's a dependency. =A0The tests depend on record working to generate t=
he
> 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 te=
sts.
>
> BTW, this raises the question whether Wine should include a tiny wave fil=
e
> for completeness. =A0Invoking the MCI Sound command always plays some sou=
nd.

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. =A0275 - 256 is 19, which you look up in mmsystem.h:
> #define MCIERR_FILE_NOT_FOUND =A0 (MCIERR_BASE + 19)

Ah yes.

>> =A0 default:
>> =A0 =A0 =A0ok(!err, "mciSendString('open') failed, expected NOERROR, got
>>%s", dbg_mcierr(err));
>> =A0 }
> In the default case, if (err) you must return (with or without skip messa=
ge).
> You cannot continue if open fails. =A0So it summarizes to:
> if (err) {
> =A0 =A0/* list of situations that were analysed as "usual": */
> =A0 =A0ok(err=3DFILE_NOT_FOUND || err=3D=3DMCIERR_CANNOT_LOAD_DRIVER || e=
rr=3D=3Dxyz ...);
> =A0 skip("Cannot test playback, cause %s",dbg_mcierr(err));
> =A0 return
> }
>
>> =A0 case MCIERR_CANNOT_LOAD_DRIVER:
>> =A0 2. =A0sound is not present on the system.
> Perhaps there's a misconception? That's not how MS-Windows systems withou=
t
> sound drivers present themselves. =A0Ge's, Paul's and my father in law's
> machines all include the MCI (and waveaudio.dll etc.). =A0It'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 gene=
rates 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=3D=3DMCIERR_FILE_NOT_FOUND || err=3D=3D...) {
   skip("Cannot test playback (err=3D%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