http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #50 from Jörg Höhle hoehle@users.sourceforge.net 2012-09-27 03:07:44 CDT --- I've yet to try it out ... Things I noted:
o It's time to add and use: #define QUIRK_PULSE 1 with make_handle_underrun_config: This->quirks |= QUIRK_PULSE;
o if(err < 0 || alsa_period_us < period / 10) Formerly, the check err<0 followed snd_pcm_hw_params_set_period_time_near Now you have a larger cascade involving err<0. Does it do what you want?
o AudioClient_Start + if(This->dataflow == eRender){ + snd_pcm_avail_update(This->pcm_handle); What's the purpose of this? IIRC, PA's avail_update was unreliable before it had really started (or am I confusing that with OSS?).
o There are now 3 timers - CreatetimerQueue - gettimeofday - the ALSA device's timer None of these are sync'ed. I doubt anybody can prove that the code works correctly in the long run. That's my big conceptual gripe.
I too got the feeling that PA might behave when it's not fed too much data, but how to best achieve that without introducing clock skew issues?
Rejuvenation might be another idea, i.e. snd_pcm_close + snd_pcm_open as soon as we detect that PA misbehaves. However IIRC my testing showed that PA's broken state was persistent across client processes.