Wine sound discussion summary
m.b.lankhorst at gmail.com
Tue Dec 8 00:48:36 CST 2009
2009/12/8 Robert Reif <reif at earthlink.net>:
> Francois Gouget wrote:
>> Also, as far as I know, DirectSound works on top of all our backend
> 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..
> 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..
More information about the wine-devel