winealsa.drv patch to enum all software devices from .asoundrc

[Chris Robinson]

On Wednesday, February 22, 2012 11:42:13 AM Joerg-Cyril.Hoehle at 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.