Hi,
I agree that dsound -> winmm -> mmdevapi is an abomination.
However, this all goes too fast for me. We don't have a fool-proof mmdevapi yet (neither ALSA, nor OSS, nor CoreAudio). We don't have a bug-free winmm->mmdevapi yet.
Since June, I've done nothing than analyse code and fix bugs to help The Wine project in my free time. My wife has already signaled that she's not pleased. I've installed zero SW for the children since that time. Well, my choice, but I'm growing tired.
It appears that I've a biased view on the current audio situation because I see all the bugs. The user experience does not seem that bad, from what a few users told me.
Currently, having dsound -> winmm -> mmdevapi may not be satisfying, but it helps to find hairy bugs fast (more apps use dsound than winmm).
After the initial winmm transition, I did not even look at dsound or winmm bugs because there's no point in doing so when they depend on a mmdevapi which is not yet robust enough. So I concentrated on mmdevapi. It's only recently that I've started to look at winmm now that I believe to know well most remaining ALSA and CoreAudio mmdevapi bugs. I'm solely starting on OSS bugs.
I believe users are happy to still have dsound HW acceleration in ALSA since 1.3.25 to compare it with the new HW emulation behaviour via mmdevapi.
Is a 1.4 release target this year the reason for pushing out code fast?
Regards, Jörg Höhle