I don't have issues with what Maarten is trying to accomplish. In fact
I'm happy to see someone making a serious effort to fix wine audio.
What I do have serious issue with is the way he is attacking the problem.
The windows 95 driver model is not a bad model. If you look at the
winmm driver API and the winmm API, they are virtually the same. The
same is true for the direct sound driver API and the direct sound API.
Under ideal circumstances the winmm and direct sound dlls are doing
nothing but marshaling between user space and kernel space. An
application is virtually interfacing directly with the audio driver.
The problem with the windows 95 driver model is that the user experience
depends totally on the quality of the sound driver and sound hardware.
If the hardware doesn't do something, an application using it also can't
do it. Microsoft redesigned their sound system to provide consistent
audio capabilities regardless of the hardware capabilities by placing
software between the drivers and the APIs to change whatever the APIs
requested to something the hardware can handle. Also because all audio
drivers were virtually the same, they also refactored the audio system
to place common code in intermediate software layers.
The problems Microsoft had are the same problems wine currently has:
inconsistent audio experience. Wine audio works fine for some people
and not at all for others because the hardware and operating system and
audio API they are using are different.
The approach Maarten is taking by starting with direct sound is
backwards and will cause serious regressions. You can't just throw out
working code that applications use just because most people won't
notice. Maarten has admitted that he will have to develop an openal
winmm driver but not right away. What he should do is develop that
driver first and get it working well along side the current drivers.
This won't immediately help direct sound but direct sound will be able
to use it.
The next step should be to decide if we want to use openal as the one
and only audio API in wine. If so, then we have two approaches to do
that. We can add a direct sound API to the openal winmm driver just
like we do with existing drivers or put openal code in the direct sound
dll. If we are absolutely confident that the openal winmm driver can
operate properly with the openal direct sound dll at the same time, then
that would be a reasonable approach. The only down side is that audio
code is not centralized. If state needs to be shared between the two
APIs, then a single driver is the best approach.
The big problem with the current direct sound dll is that it must do
software mixing and format and sample rate conversions when the low
level driver doesn't do what the application requested. In wine, none
of the drivers can do what is requested. If the low level driver was
guaranteed to do anything the application requested, we could remove
that code. Then we are down to just marshaling between the app and the
audio driver or API.
We need a design approach and a road map and an agreement that the
approach is correct. We also need to insure that regressions are not
introduced during the process. I would like to see an incremental
solution that doesn't introduce regressions. That is developing an
openal winmm driver first and then address the best solution for the
direct sound issue later. Not the other way around.
