[PATCH 7/9] dsound: Reimplement rendering devices on mmdevapi

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

[Andrew Eikum]

On Mon, Sep 26, 2011 at 05:05:28PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> 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.

This is a valid worry/complaint.

The reason I wanted to get all of the 'big stuff' (mmdevapi, winmm,
dsound rewrites) out of the way quickly was so I can start focusing on
the bugs. I have been largely ignoring dsound bugs, since I knew
dsound was going to be reworked anyway. I certainly had no interest in
fixing bugs with dsound set to Full hardware acceleration, which is
the default, since almost all of that code was going to disappear.
With the dsound->mmdevapi conversion work done, I think it's worth
spending time investigating and fixing the dsound bugs. I'd much
rather spend time on the bugs once we've got the "permanent" code in
place, than messing around with code that's going to be significantly
reworked anyway.

I know it's frustrating in the meanwhile, but I really feel that it's
not in as bad a situation as you think. At least I think it's much
more pleasant to debug the new code than the old :)
> 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.

dsound hwaccel mode really puts a wrench in getting good quality bug
reports. Users don't understand all of the different audio options and
often don't include that information in bugs. Killing hwaccel is
something I want to do absolutely as soon as possible. Getting a
handful of new dsound->winmm->mmdevapi->driver bugs hardly seems
worth it when we're going to convert to the new chain anyway, so I
thought do it all at once.

Andrew