http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #85 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-14 09:22:28 CST ---
We can't set max(3xperiod) because then [...] on someone's system.
I see. Too bad.
they already have at least 3 ALSA periods in their buffer by default
No idea. I've typically observed 4-6, but I feel ALSA ought to work with 2.
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.
I've not yet thought about the smallest buffer size that winealsa needs to work.
+ 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.
"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.
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.