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 #80 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-09 10:54:53 CST --- GetPosition patch submitted http://www.winehq.org/pipermail/wine-patches/2011-December/109646.html
Perhaps s/5/EIO/ here:
/* Pulse bug: err -5 shortly after starting: nothing played */
Done. -5 is what people see in the logs and I'm fed up with googling the possible ERR* name when reading Spanish, Russian, Polish or Ukrainian snd_strerr() output in logs submitted to the bugtracker. IMHO it should print the symbolic name too.
Removed Target Milestone
!?! No idea. Restored.
Does the same bug affect delay_frames as well?
Yes, I updated the comment. I really observed cases where avail would resume from former values despite intermittent snd_pcm_reset, and snd_pcm_delay would reflect that too. It looks like PA doesn't master its backend. I fear the comments are not enough to understand the PulseAudio and rate plugin mess when you'll read the code in 2 years or later.
Note that PulseAudio in the old Ubuntu Intrepid produces reasonable values with Andrew's "draining" patch from comment #54, whereas the more recent PulseAudio in Ubuntu Lucid (LTS) is broken beyond repair, so it seems. I wonder what kind of testsuite that project is using.
if(duration <= 80ms) /* app shows it wants tight timing */ set_hw_params_period_time max(20ms); /* abort on error not shown */
Well, plug:dmix' minimum appears to be 21.333ms in Ubuntu (@8000x1x8)... That code would fail to initialize! Something else is needed.
1s, then it would end up in sound lagging 2s
Unless we play native, implement a mixer running constantly. BTW, regarding comment #51, I've now received comments about Linux CFS causing not only audio delays but also video drop outs. If you want to play games, you better use a kernel < 2.6.23 and no backports or you manage to compile Linux without the Completely Fair Scheduler.
Now that we've seen (from a few tests) that the GetPosition patch stands on its own, what about the "change drain behaviour" patch and the 2 subsequent ones? Are they ready to enter Wine and be later replaced by the lead-in concept (once written and proven) and a "GetCurrentPadding modulo mmdev period size" patch? Or should we dump them and wait for the lead-in?
I propose: 1. "change drain behaviour" (which I need to review closely); 2. Modify "set ALSA period size" to set_period_near 10ms; Maybe that's enough for Rage in Alexey's case? 3. Modify "request big enough buffer" to match native's clamping of values and rounding (using MulDiv).
Later: stable 10ms Rage sound (if Linux can take it), 10ms padding increments, better underrun handling, ...