Hi Eric,
Eric Pouech wrote:
Another thing i wonder about is whether Windows lets you play 11kHz sounds with WAVE_FORMAT_DIRECT using winmm and an i810 soundcard. If not then my winmm test is incorrect, and if yes then I have to wonder what WAVE_FORMAT_DIRECT really means. So if someone can send me these results...
well, it may also depends on who is in charge to "understand" the WAVE_FORMAT_DIRECT:
- from what I understand from the doc (I didn't actually tested under
windows), WAVE_FORMAT_DIRECT tells winmm not to perform frequency modification if the driver doesn't support the requested format
- it doesn't state that the driver shouldn't do any transformation by
itself
That's an interesting interpretation. How would one go about testing it under Windows? Under your interpretation, even if we specify WAVE_FORMAT_DIRECT the sample rate may still be performed by either the driver or the hardware. The values returned by Windows really muddle what's being done in software and what's being done in hardware :-( however if we assume that the above soundcard can really only handle 48kHz then yours seems like the correct hypothesis.
That actually reminds me of waveOutGetDevCaps. On Windows it seems to return an awful lot of supported formats. Up to now my hypothesis was that it returned everything that the wavemapper was able to convert to a supported format. But maybe this is wrong and it should only report what the *driver* can handle (possibly in software). So for us this means wineoss should perform a strict conversion of the mask returned by SNDCTL_DSP_GETFMTS to the Windows set of flags, with no stereo/mono, 8/16 bit muddling.
So with an i810 soundcard and the OSS driver we would only get 48000x16x2, and with Alsa (accessed through OSS) we would get whatever Alsa is able to convert to a format supported by the soundcard.
Hmm, I guess this means we're still stuck with trying multiple formats for mmap :-(
[...]
I don't know why the mmap fails. I would tend to think this is a limitation or bug of the Alsa driver since it works with the OSS driver.
do you mean
- wine OSS driver on a Linux OSS emulation on ALSA driver
- or wine ALSA driver on a Linux ALSA driver
the later could have still quite a few issues
I'm only working on the wineoss driver... at least for now.
anyway, there are also a couple of issues we may have to look after:
- the driver interface used always comes from a single audio driver
(even if multiple audio drivers are installed in wine)
- trying to get rid of wine's DRV_QUERYDSOUNDIFACE... a bit more
hacky... one solution would be (as MS does) to install in the registry all the required settings for our sound drivers (including a guid for each wave out, wave in... so that we could bind dsound to each of those drivers)
- getting rid of WAVE_DIRECTSOUND... I didn't look at all the details...
but, wouldn't the semantics of open&setformat methods of the IDsDriver be enough for that
These sound good but I don't really feel qualified enough yet to comment on them (or be able to contribute much I'm afraid).