Wine sound discussion summary

[Robert Reif]

Maarten Lankhorst wrote:
> Hi Reif,
>
> 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
>>> 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.