http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #45 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-11 17:16:32 CST ---
I can't find where in the comment #19 I had been talking about 100% prefill (you're considering 30ms duration / 10ms period case, right?).
No. I was considering a 10ms period and a 40ms buffer filled 3/4 = 30ms you mentioned in comment #24 even though that requires a period >= 10.5ms as you explain in comment #19.
Data that had been received through GetBuffer()/ReleaseBuffer() calls might be immediately pumped out to ALSA. Jörg, you had mentioned that there are some constraints against acting in a such way
When you pump out data at fixed intervals, you can reason about the properties of your system: - if ALSA has less than mmdev_period samples after my write, there'll be an underrun. - if ALSA has not started yet and I write less than alsa_period samples, then it may not start -- bug #29056 -- so I must fill it up, which should be safe, as the app did not write more data in this (mmdev) period. - Get/ReleaseBuffer is presumably a fast operation in native, so the app never blocks. ReleaseBuffer used to wait while writing to OSS, see bug #28056, comment #35. - Several threads writing to the same ALSA stream, hmm... - You can even add code to detect that sound hung during the last events and reinitialize it.
If you write data anytime, you can't decide anything because you don't know whether the app may call Get/ReleaseBuffer again within the next millisecond. Yet I think that a heuristic like "if near underrun, feed ALSA a little" may be ok, nevertheless one must carefully assess how this affects GetCurrentPadding, as your analysis shows, and how to solve bug #29056, i.e. when to pad with silence.