http://bugs.winehq.org/show_bug.cgi?id=28723 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.4.0 |--- --- Comment #74 from Jörg Höhle <hoehle(a)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.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.