[PATCH 5/6] dsound: rework ugly mixer logic

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Maarten Lankhorst wrote:
>For example Skyrim with a 36 ms stream latency will just buffer in more data to
>compensate instead. But it can't do it if you report that it's fine to feed data every 5 ms.

Please elaborate.  Every now and then I wish you used more words to
explain your observations.

Where do the 5ms come from?  What's the relationship with the 36ms latency?

You patch DSound so I assume that Skyrim uses DSound, not mmdevapi
directly.  Shouldn't DSound export capabilities that make sense given
its abstraction?  IIRC, there's some former mailto wine-devel or bug
report where I talked about the alternating period-sized buffer
abstraction that is underlying DSound's API and how all positions
being reported modulo buffer size are problematic if someone misses
the period intervals.
Of course, that abstraction cannot explain a 36ms latency with two
alternating period-sized "direct hardware" buffers of 5ms.

Wine's DSound must maintain a set of mutually consistent variables
{ play position, write position, buffer size, period size }
that in addition need to make sense w.r.t. audio output.
I'm not convinced that it does.  There should be tests to verify that.

In particular, wine's DSound must not let play position leave the virtual DSound
buffer, even if mmdevapi reports that it's 2 seconds behind with PulseAudio.
(IMHO, should that happen, then DSound must cap the reported position).

(BTW, I'd find it easier for Wine if DSound's primary were equal to mmdevapi's
buffer, except that with winecoreaudio, there's no such mmdevapi buffer...)

Regards,
	Jörg Höhle