DirectSound and i810 soundcards

[Francois Gouget]

Ove Kaaven wrote:
> On Mon, 6 Jan 2003, Francois Gouget wrote:
[...]
> 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.

Ah that probably explains some results I've seen then. Thanks.


>>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.)

Ok. That makes sense. That's sort of the opposite direction of the 
DirectSound patch I sent to wine-patches (and which just got applied). 
The annoying thing is that the mmap, the device format bubbling up and 
the CreateThread are all in different places :-(
Oh well, I'll try to come up with something. It seems hacking things to 
make mmap succeeds is the simplest approach. But what's the best approach?

  1. if we tweak things so that the mmap call succeeds then Wine will be 
making the resampling. And Wine is not really good at that and tends to 
introduce audible distortion. It probably doesn't matter if you start 
from an 8kHz signal but if you're playing a 44kHz sound...

  2. if we tweak things so that the CreateThread is done, then the 
resampling will be done by Alsa (or whichever back-end) which will 
presumably do it much better than us. howeve rin that case we have to 
make the almost never used case work and I'm not sure how well it would 
work anyway (I'm concerned about skips/cracks/pops).

To make 1. cleaner maybe we should have a Wine-specific message that 
asks the backend to return the formats supported by the device, i.e. for 
OSS returning an exact translation of the value returned by 
SNDCTL_DSP_GETFMTS.
Then if our msacm gets improved to the Jack sound format conversion 
library we're golden... (what's the status of this btw?)


-- 
Francois Gouget
fgouget at codeweavers.com