DirectSound and i810 soundcards

[Ove Kaaven]

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>