http://bugs.winehq.org/show_bug.cgi?id=28723
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.4.0 |---
--- Comment #74 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-08 05:05:51 CST ---
"the device position never decreases from one reading to the next."
Exactly. When I was at school, mononotic by default implied not strictly.
After more testing with the rate plugins and failing underrun detection, I think I'll add: if(0 < delay_frames < alsa_period) This->last_pos = written-mmdev_padding; to accept the current value once but make sure GP bumps to maximum the next time it's called -- instead of immediately bumping to max. The effect is close to your observation about native in comment #65.
pump-out 2*alsa_period audio data in advance
How? Rage only gives you 10ms and you cannot predict the future. That's what lead me to the idea of extending time in the other direction and introduce the 10ms lead-in, comment #58. If ALSA period is say 50ms, then the lead-in must be of similar size. Alas, lead-ins increase underrun recovery time. I've read that PulseAudio uses snd_pcm_rewind to overwrite (when mixing) already written data with new samples. You could try out that route however my experience with seeking with snd_pcm_forward is bad, see bug #28517.