On Sat, 28 Dec 2002, Francois Gouget wrote:
When DSound initializes it create a primary sound buffer and invokes winmm to actually get access to a sound device. The default format of the primary buffer is 22050x16x2 (i.e. 22050Hz, 16 bit sound, stereo). This means the device it's going to get will be handled by msacm.drv which will be responsible for performing the conversions on the fly.
However during the primary buffer creation DSDB_MapPrimary gets invoked in wineoss and does an mmap of the hardware sound buffer.
So when we then play sound in a secondary sound buffer, this sound gets mixed into the primary buffer, but because of the mmap this then goes straight to the sound card with no further conversion. So you end up with a chipmunk sound effect since you play a 22050x16x2 sound at 48000x16x2.
I will try to make more tests to confirm this but does it seem to make sense? Should I look in some other direction? Any suggestion about a fix?
I've been meaning to submit the winex wineoss modifications, but haven't got around to it yet, and it might be somewhat complicated by all the changes around it lately. But this particular issue doesn't take a big patch. Basically the 'true' sample rate should be propagated back to dsound, so that it knows that the primary buffer is 48kHz and can resample secondary buffers accordingly. No changes is needed to dsound for this, wineoss's wodOpen just need to modify its waveformat input parameter if the WAVE_DIRECTSOUND flag is present, then dsound will happily convert secondary buffers to that sample rate when mixing them into the primary buffer. (Primary buffers are different, but apps that writes directly into the primary buffer are few, and they should use GetFormat and resample on their own.)