http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #81 from Alexey Loukianov mooroon2@mail.ru 2011-12-09 12:08:23 CST --- (In reply to comment #80)
I wonder what kind of testsuite that project is using.
We all know that PA is a real pain in the ass :-). Actually the first advice I give at work when a customer calls and complains about misbehaving the sound-related software produced by the company I work is to get rid of the PA and never install it back. Helps to fix about 90% of failures.
Well, plug:dmix' minimum appears to be 21.333ms in Ubuntu (@8000x1x8)... That code would fail to initialize! Something else is needed.
I see at least two possible approaches: a) Run a loop starting from period size 10ms trying to set time_max and doubling it in case try fails. b) Use time_near with desired period time and hope that ALSA would be smart enough and provide us closest match that is supported.
1s, then it would end up in sound lagging 2s
Unless we play native, implement a mixer running constantly.
I'm not a fun of implementing yet another sound mixer in Wine. We already got one in DS and most users have yet another one already running on their systems (dmix or PA most of the times). And playing native won't safe us from lag that is equal to at least one alsa_period, as to play safe we have to upload at least this amount of data to ALSA at the stream start and on underrun recovery. IMO playing native won't be of a much benefit for this specific case.
I propose:
- "change drain behaviour" (which I need to review closely);
- Modify "set ALSA period size" to set_period_near 10ms;
Maybe that's enough for Rage in Alexey's case?
I bet that it most probably would be enough to fix this Rage-specific case.