Robert Reif a écrit :
Fixes a bug where waveOutGetDevCapsA succeeds with the WAVE_MAPPER device when there are no devices.
I'm not sure this is best fix because the code is hard to follow but it does work.
I'm not sure it's the right place to fix it. Did you try on windows what happens with waveOutGetDevCaps(-1, ...) to see what Windows returns for the mapper itself. The current code (in mapper) assumes that mapper itself has capabilities (which I'm not sure of). It may well be that we shall return an error (independently on the number of installed drivers), but in that case, proper support is better in the wave mapper it self than in winmm.
A+
This problem was found while looking at the winetest results. Windows returns an error when asked to get the capabilities of the default device when there are no devices present. This makes sense because you have to have at least one device to have a default one.
Wine on the other hand doesn't return an error when there are no devices. I haven't looked at the data it returns but it must be uninitialized garbage because there is no device to return the capabilities of.
After stepping through the code, the line that I changed is the line that should have returned the error but didn't. The existing code basically is: if the requested device is the default device and the default device is not set to a valid device, return an error. Unfortunately the default device is set to a something (0) in the case where no devices are present.
The code I added just makes sure there is at least one device when asking for the default device. What I assume is happening is that the default device is not being initialized properly in the case where there are no devices and that's the real problem.
The code is real hard to follow because of the macros used and the -1 array index. I'm not sure what is really happening so I just added the extra sanity check to fix the problem. Thats why I'm not sure this is the proper fix.
Eric Pouech wrote:
Robert Reif a écrit :
Fixes a bug where waveOutGetDevCapsA succeeds with the WAVE_MAPPER device when there are no devices.
I'm not sure this is best fix because the code is hard to follow but it does work.
I'm not sure it's the right place to fix it. Did you try on windows what happens with waveOutGetDevCaps(-1, ...) to see what Windows returns for the mapper itself. The current code (in mapper) assumes that mapper itself has capabilities (which I'm not sure of). It may well be that we shall return an error (independently on the number of installed drivers), but in that case, proper support is better in the wave mapper it self than in winmm.
A+
Wine on the other hand doesn't return an error when there are no devices. I haven't looked at the data it returns but it must be uninitialized garbage because there is no device to return the capabilities of.
not exactly. The wave mapper itself (dlls/winmm/wavemap/wavemap.c, function wodGetCaps) does return something.
After stepping through the code, the line that I changed is the line that should have returned the error but didn't. The existing code basically is: if the requested device is the default device and the default device is not set to a valid device, return an error.
it's not the default device, it's the mapper. It's up to the mapper to actually pick up what is supposed to be the default device. The existing code does (lolvldrv.c, in MMDRV_GetById): - in the current class of device (in your case wave out), if the ID is the one of the mapper, and a mapper exists for the class, then use the device of the mapper as the real device
That's why I suggested that wavemap is more likely to be fixed rather than winmm itself. I do think that what windows do for waveOutGetDevCaps(-1...) is: - in winmm, get -1 as the mapper and pass the WODM_GETDEVCAPS to the mapper driver - in wavemap, while handling WODM_GETDEVCAPS, pass the message to the default device This last part is broken right now (from what you report). It should then pass the WODM_GETDEVCAPS to the actual default device (it already does it if first waveOutGetDevCaps is called with a handle and not a device ID), instead of returning values for the mapper (which is not very sensible).
A+
-
Eric Pouech -
Robert Reif