That's an interesting interpretation. How would one go about testing it under Windows?
you would have to load the MM driver by hand and directly send the messages to it however, depending on the Windows version you're using, interfaces may differ.
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.
except if we decide at the driver level to support more format... we could also decide that if OSS fails to open a driver (even with the wave direct flag set) to do the format conversion at the driver level IMO, that's just an implementation decision. we're not obliged to stick to the pure capability of the MM driver we rely upon.
Hmm, I guess this means we're still stuck with trying multiple formats for mmap :-(
the current dsound implementation however, already supports the format conversion anyway... so basically the implementation would be, in order of trials (for OSS): - mmap with required format - mmap with any available format on the soundcard (using the OSS capability would help here) - regular wavehdr playing
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).
since Ove jumped in to discuss the other issues, I found it appropriate to fire this part too ;-) A+