http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #73 from Alexey Loukianov mooroon2@mail.ru 2011-12-07 05:10:37 CST --- Thanks for submitting new patch, would take a look on it this evening.
As for making short periods a hard requirement - wouldn't it be nicer to add-up latency and emulate required period timing in software (actually it is already as timer callbacks are independent from ALSA periods) rather than failing completely? I.e. if ALSA reports that it supports requested small period - excellent, use it. If not - pump-out 2*alsa_period audio data in advance to ALSA and then continue feeding it with alsa_period data every alsa_period elapses at the same time keeping firing up events every emulated mmdev_period.
P.S. Concerning monotonically increasing GetPosition(): by "monotonically" here you mean standard math definition for term "monotonically" (i.e. derivative for func is always greater or equal to zero)? To be more precise, it'd be more correctly define GP as monotonically non-strictly increasing sequence - we're in digital world here so there's no such thing as a real continuity here. If you meant that - it's sort of documented in MSDN (quote from GetPosition() docs, see remarks section): "... The device position is a stream-relative offset. ... Immediately following creation of a new stream, the device position is 0. Following a call to the IAudioClient::Start method, the device position increments at a uniform rate. ... Successive device readings are monotonically increasing. Although the device position might not change between two successive readings, the device position never decreases from one reading to the next. ...".