http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #86 from Andrew Eikum aeikum@codeweavers.com 2011-12-14 09:39:23 CST --- (In reply to comment #85)
We now use set_buffer_size_min() instead of _near().
That's a bad move. near is a clear indicator of what we want. min or max are completely ignored unless the limit is hit during constraint resolution. As a result, with min only, PA will use its typical 2s buffer.
But _near() runs the same risk as _max(), that is, it allows ALSA to give us too small a buffer (Bug 28282). Other than wasting memory, what's the harm of a 2s buffer since we limit our writes in alsa_write_data() anyway?
- if(period)
This->mmdev_period_rt = period;I'd like to eventually see if(!period || mode==SHARED) = DefaultPeriod I'm currently using testbot to obtain the min & max values.
This is patch 4 in the patchset.
"while () write_limit+=;"
I've had cases with alsa_period=8 frames vs 448 mmdevapi period. That needs quite a few iterations through the loop and should be replaced by a straight formula to directly compute the limit instead.
But we add max_period to write_limit in the loop body, so I'm pretty sure the loop can execute at most three times.
I've made some progress with PA. The sequence prepare + drop + prepare(!) manages to prevent the too large avail & delay values reported in comment #63 past an underrun, at least with the old Ubuntu Intrepid PA. There's still an issue that it may spit out a sequence of "handling underrun" for over 100ms until it gets back to normal behaviour.
Are these future concerns, or do you think they should block this patchset? I would really like to get it in ASAP.
We should also talk about attribution. I am fine with the following: 1/4 goes to Alexey 2/4 goes to Jörg 3/4 and 4/4 go to me (unless you want 4/4, Jörg, but it's pretty trivial) AJ tends to prefer patch that authors submit their own patches, so we'll have to either hope for an exception or submit them one-per-day or with coordinated patch counts in the subject. What a mess :)