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