Maarten Lankhorst wrote:
Hi Reif,
2009/12/8 Robert Reif reif@earthlink.net:
Francois Gouget wrote:
Also, as far as I know, DirectSound works on top of all our backend drivers.
It works through the WAVE API on most drivers which requires software mixing and format conversions. Even the direct sound drivers only implement a single hardware buffer which means that even direct sound goes through the software mixer and format conversions.
GASP, that's not such a problem that you make it out to be. Hell, winealsa even emulates a ring buffer with read calls, see f27d88e16fe..
Yes, a single ring buffer for all the software mixed direct sound buffers. A good driver implementation would have a ring buffer for every direct sound buffer. Therefore no requirement for any software mixing. That path is in the direct sound dll now but is not used because no driver supports it. In fact, when you rewrite the dll, you should be removing all existing code paths excepts this one.
If any direct sound driver implemented multiple buffers of any format, there would be no software mixing done in the direct sound dll. Everything would just pass through the direct sound dll directly to the driver untouched. We would also get multiple open support since it wouldn't matter which application the buffers came from.
The dsound timer would still tick and most of the time the app would still use the crappy remixer in dsound since games use DSBCAPS_LOCSOFTWARE these days.. Even more fundamentally, our winmm drivers are crap, full of literally copied versions of wineoss, just renamed and sedded, but never maintained. Spot the similar #if 0's...
The wavein/out drivers will be thrown out after we can forward to WASAPI, since the midi code is still handled in winmm afaict, a few of them will continue to live for that purpose..
Can I please have some new discussion point instead of you trying to bring up the same over and over? I'm growing tired of having to repeat myself so much..
I know this discussion is academic at this point but sound in wine is poor not because of a bad model but because of real poor and incomplete driver implementations. With the right driver, the current model for pre vista applications would have had no issues. This is the same problem Microsoft had and is one of the reasons they changed their audio system model.
With the introduction of vista, a new model is required but just like vista, audio capabilities will be significantly reduced and backwards compatibility will become a big issue requiring workarounds. Also putting in new incomplete drivers that don't support everything required will just be repeating the same mistakes we already made. I don't want to see a new implementation start out with the same problems that the old system had because people didn't learn any lessons. We are already talking about hacks to fix things before the new implementation is even fully conceptualized. Not a good start.