On Wednesday, February 22, 2012 11:42:13 AM joerg-cyril.hoe...@t-systems.com wrote: > That's why I'll repeat once more and say that DSound's resampler should > become that one. > > My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY > etc.) tells me it's compatible with such a scheme: there are restriction on > when you're allowed to invoke SetFormat on the Primary buffer.
DSound needs to resample itself anyway, to mix all the secondary buffers to the output stream. If winmm streams are implemented using secondary buffers on dsound, then there's no issue with making resampling as dsound will do it. I'd also wager that DSound's primary buffer is largely faked. It's telling that the primary buffer is (in tests Maarten and I have done) always 32768 bytes, even for output modes where that isn't a multiple, or where it can only hold 20ms of audio. I would say IDirectSoundBuffer::SetFormat accepts reasonable any rate, although it outputs using the mmdevapi device rate, and WRITE_PRIMARY emulates primary access by using a secondary buffer, which can be set to the specified rate.
