On Mon, 6 Jan 2003, Francois Gouget wrote:
I'm not really sure this is what Windows is doing however. I would be interested if people with Windows NT/2000/XP and an i810 soundcard could run both the dsound and the winmm tests and send me the output.
Note that test results from Windows XP won't be very useful for this; under XP, dsound primary buffers doesn't map directly to the sound hardware any more, according to MSDN. If you create and use a dsound primary buffer under XP, it will just become another stream sent to XP's kernel-mode sound mixer, before it gets to the hardware.
I believe that Windows lets you call SetFormat on the primary buffer but I'm not sure if that actually has an effect or not.
It should if you have appropriate cooperative level (except under XP).
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.
ALSA has resampling features. If you open the sound device at e.g. 11kHz, then ALSA's OSS emulation will, instead of telling you that the chip is 48kHz, install a resampling filter to convert from 11kHz to the hardware's required 48kHz. Unfortunately, that filter gets in the way of direct access, making an mmap fail. (In WineX we test mmap on a range of common frequencies to work around this.)
However it seems that we should be able to cope with this situation. But I have some questions:
- in wodOpen we create a wodPlayer thread... except if we are being
called by DirectSound. Won't we need this thread if we cannot mmap the device?
dsound used to completely fail (and return errors to the app) in this case, so it wasn't a problem. The thread should be created if mmap isn't available, yes, but that would have to be verified beforehand (that's what the cap flag checking is for), since both wodOpen and dsound needs to know whether mmap is available (to avoid the problems below).
- when we do a SetFormat, DSOUND_PrimaryClose calls waveOutReset (only
hwbuf, e.g. if mmap failed) which in turn calls OSS_AddRingMessage. However since we don't have the wodPlayer thread noone ever processes that message and we remain stuck there. What I'm currently experimenting with is not sending this message but I wonder if we should not make sure we have a wodPlayer thread instead (but then, when should we create it?).
- the next problem is that DSOUND_PrimaryClose calls
waveOutUnprepareHeader with a bunch of WAVEHDR pointers. Adding a test to avoid this condition is simple but again I wonder if this is quite normal. Am I right in thinking that this code path (hwbuf==NULL) is rarely if ever used? <g>