Maarten Lankhorst wrote:
I think the key is to use accurate periods and report GetStreamLatency correctly.
You mentioned GSL in the past already, and I think it makes sense to return real values instead of native's 10.6667 that I don't trust, however I expect nothing from setting it:
http://bugs.winehq.org/show_bug.cgi?id=28723#c23 "It looks like XA2 doesn't calls it at all."
Or never use anything but dmix/real hardware with winealsa
Well, there's bug #28781 and #29294 from the Jack users :-)
I've ran some numeric simulations tonight and am beginning to see some light with an ALSA design that meets all my design goals but one: + arbitrarily large ALSA buffer that would avoid underruns if Linux has other stuff to do for 100ms if the feeder supplies enough data (e.g. winmm would typically be safe, XAudio2 will lose out). + variable latency (conceivably user settable via registry) aka. "hidden frames" + accommodates crazy irregular wake-ups + exhibits very regular period-size decrease of padding + self-correcting timer and adaption to clock skew - alas, needs a wake-up even without EVENTCALLBACK
Regards, Jörg