http://bugs.winehq.org/show_bug.cgi?id=28723 --- Comment #85 from Jörg Höhle <hoehle(a)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. -- 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.