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